Methods for implementing virtual bases with fixed offsets in object oriented applications

ABSTRACT

There is provided a method for implementing virtual bases with fixed offsets in a class hierarchy graph corresponding to an object oriented program. The graph has nodes representing object classes and edges representing immediate inheritance therebetween. The method includes the step of determining whether a set N is empty, the set N including all nodes in the graph. A node x is removed from the set N, when the set N is not empty. It is determined whether a set Y is empty, the set Y including nodes that directly and virtually inherit from the node x. A return is made to the step of determining whether the set N is empty, when the set Y is empty. A node y is removed from the set Y, when the set Y is not empty. It is determined whether the node y is duplicated in the graph. A return is made to the step of determining whether the set Y is empty, when the node y is duplicated. An edge e is replaced with an edge e′, when the node y is not duplicated. The edge e represents that the node y virtually inherits from the node x. The edge e′ represents that the node x has a fixed offset with respect to the node y. A return is made to the step of determining whether the set N is empty, upon replacing the edge e.

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application is related to the application (Docket NumberYO999-209) entitled “Methods for Laying Out Memories Bidirectionally forObject Oriented Applications”, which is commonly assigned and is filedconcurrently with the present invention.

BACKGROUND

[0002] 1. Technical Field

[0003] The present invention relates generally to object-orientedprogramming (OOP) and, in particular, to methods for implementingvirtual bases with fixed offsets in object oriented applications.

[0004] 2. Background Description

[0005] Object oriented programming (OOP) is the preferred environmentfor building user-friendly, intelligent computer software. The objectoriented paradigm is a programming paradigm in which the world ismodeled as a collection of self-contained objects that interact bysending messages. Objects are modules that contain data and allfunctions (code) that are allowed to be performed on the encapsulateddata. Objects are defined by class (type), which determine everythingabout an object. Moreover, objects are considered as individualinstances of a class.

[0006] Examples of OOP languages include C++, SMALLTALK, and JAVA, amongothers. C++ is an object oriented version of C. It is compatible with C,so that existing C code can be incorporated into C++ programs.

[0007] SMALLTALK is a pure object oriented language. In SMALLTALK, amessage is sent to an object to evaluate the object itself. Messagesperform a task similar to that of function calls in conventionalprogramming languages. The programmer does not need to be concerned withthe type of data. Rather, the programmer need only be concerned withcreating the right order of a message and using the message.

[0008] JAVA is designed as a portable object oriented language that canrun on any web-enabled computer via that computer's Web browser. Assuch, it offers great promise as the standard Internet and Intranetprogramming language. JAVA is an interpreted language that uses anintermediate language. The source code of a JAVA program is compiledinto “byte code”, which cannot be run by itself. The byte code must beconverted into machine code at runtime. Upon finding a JAVA applet, theWeb browser switches to its JAVA interpreter (JAVA Virtual Machine)which translates the byte code into machine code and runs it. This meansJAVA programs are not dependent on any specific hardware and will run inany computer with the JAVA virtual machine. For a detailed referencedescribing JAVA, see “The JAVA Programming Language”, K. Arnold and J.Gosling, The JAVA Series, Addison-Wesley, 1996.

[0009] There are several key elements that characterize OOP. Theyinclude virtual functions, polymorphism, and inheritance. These elementsare used to generate a graphical user interface (GUI), typicallycharacterized by a windows environment having icons, mouse cursors, andmenus. While these three key elements are common to OOP languages, mostOOP languages implement the three elements differently.

[0010] A virtual function is a function that has a default operation fora parent (base) class, but which can be overridden to perform adifferent operation by a child (derived) class. Thus, implicit invirtual function invocation is the idea that the execution of a virtualfunction can vary with different objects, i.e., the behavior andresponse that the invocation elicits will depend on the object throughwhich the function is invoked.

[0011] Polymorphism refers to the substitutability of related objects.Objects are “related” if they have a similar “type”, and in mostobject-oriented languages that means that they are instances of the sameclass, or they have a common parent class through inheritance.Polymorphism allows this shared code to be tailored to fit the specificcircumstances of each individual data type.

[0012] Inheritance lets classes be defined in terms of other classes.Thus, inheritance allows different classes to share the same code,leading to a reduction in code size and an increase in functionality. Aclass that inherits from another class is called a “subclass” or “child”of the other class (which is called the “superclass” or “parent class”).The subclass responds to the same messages as its parent, and it mayrespond to additional messages as well. The subclass “inherits” itsimplementation from its parent, though it may choose to reimplement somemethods and/or add more data. Inheritance lets programmers define newclasses easily as incremental refinements of existing ones.

[0013] There are various types of inheritance in OOP. Single inheritancecorresponds to a class that has no more than one parent (base) class.Multiple inheritance corresponds to a class that can contain more thanone parent. Virtual inheritance is when a base class inherited alongdistinct paths occurs only once in the derived class. That is, the(derived) sub-object is not replicated. Non-virtual inheritance is whenthe base class has multiple distinct occurrences in the derived class.That is, the (derived) sub-object is replicated.

[0014] Virtual and non-virtual inheritance are phrases employed withrespect to the C++ programming language. However, such inheritancesexist in other object-oriented programming languages, although they maybe referred to by different phrases. For example, virtual andnon-virtual inheritance correspond to shared and repeated inheritance,respectively, in the Eiffel programming language.

[0015] A brief description of multiple inheritance with respect to theC++ programming language will now be given. As noted by B. Stroustrup,in The C++ Programming Language, Addison-Wesley, 3rd Ed. (1997), the C++syntax forces a programmer to select the kind (or semantics) ofinheritance, virtual and non-virtual, when the inheritance occurs. Thatis, the derived class must specify whether the base class is inheritednonvirtually or virtually.

[0016] This selection forces the programmer to anticipate all possiblecontexts in which the classes may be further derived and allows only onechoice for all of them. In the case of extendible libraries or anyclasses that have the potential to be further derived, the programmer isinclined therefore to conservatively specify the type of all occurrencesof inheritance as virtual since no assumption of how the classes may bederived in the future are possible.

[0017] This predicament is made even greater by the non-negligible toll,both in terms of space and time resources, taken by the standardimplementation of virtual inheritance in C++. This toll is furtherdescribed by Ellis and B. Stroustrup, in The Annotated C++ ReferenceManual, Addison-Wesley, January 1994. The representation of each objectof any class must include the set of offsets to all of its virtual baseclasses. Although these offsets can be shared among objects of the sameclass by storing the offsets in class tables, time-efficientimplementations will repeatedly store these offsets, usually aspointers, in each instance of the class. Furthermore, these pointers arenot usually shared across virtual inheritance. The time penalty isincurred when these pointers are to be dereferenced e.g., in an upcast,a call to an inherited (even nonvirtual) member function, or inreference to data members of the virtual base. These operations requireat least one indirection, and two indirections in the implementationwhere the offsets are stored per class and not per object.

[0018] A brief description of some of the terminology and notations usedherein will now be given. Moreover, some of the various graphicalnotations used herein with respect inheritance hierarchies, objectlayout diagrams and subobject graphs are illustrated in FIG. 1. Thenouns “instance” and “object” are used interchangeably, as are the verbs“inherit” and “derive”. Since the implementation of virtual inheritancein the traditional layout scheme is the same, regardless of whether itis singular or multiple, we will sometimes use the term multipleinheritance in a loose sense, to also include single virtualinheritance.

[0019] Lower case letters from the beginning and the end of the Latinalphabet, e.g., a₁, b₁, . . . and u₁, v₁, w₁, x₁, y₁, z denote classes.In addition, u₁, v₁, w₁, x₁, Y₁, z are also used for denoting variablesranging over the domain of all classes, principally in procedures andtheorems. By writing x≦y we mean that either x=y or x inherits, directlyor indirectly from y. We say that x is a descendant of y and that y isan ancestor or a base of x. The strict inequality x<y is used to saythat x<y and x=y or, in words, x is a proper descendant of y and y is aproper ancestor of x.

[0020] Immediate (or direct) inheritance is denoted by <. Thus, x<ymeans that y is an immediate base of x, without specifying the kind ofinheritance between x and y. To state that y is an immediate virtual(shared) base of x we write x<_(v)y, whereas x<_(r)y means that y is animmediate nonvirtual (repeated) base of x.

[0021] We assume that a class cannot be an immediate base of anotherclass more than once. This assumption makes it possible to model theinheritance hierarchy of an object oriented program as a graph, ratherthan a multi-graph. In such a graph, which is directed and acyclic,classes are represented as nodes and immediate inheritance isrepresented as edges. The relationship x<y is represented by the edge(x<y) leading from the node x to the node y.

[0022] Although there are many variations to it, there is basically onecommon scheme for laying out C++ objects in memory. The scheme, which ishereinafter referred to as the traditional layout, is used by the vastmajority of C++ compilers. Other languages that want to efficientlysupport multiple inheritance need a similar layout scheme.

[0023] A brief review of the traditional layout will now be given forthe purpose of setting out the context in which the optimizationtechniques of the present invention take place. A more detaileddescription of the traditional layout can be found in standard textbookssuch as: The Annotated C++ Reference Manual, Ellis and B. Stroustrup,Addison-Wesley, January 1994; Inside The C++ Object Model, S. B.Lippman, Addison-Wesley, second edition, 1996; and The Design andEvolution of C++, B. Stroustrup, Addison-Wesley, March 1994. Therelative merits of the variants of this layout in terms of the spaceoverhead they impose is described by P. Sweeney and M. Burke, in theabove referenced article entitled “A Methodology for Quantifying andEvaluating the Space Overhead in C++ Object Models”.

[0024] With respect to implementing multiple inheritance there are twolanguage features that incur a space (and time) overhead: virtualfunctions; and virtual inheritance. Virtual functions are implementedusing pointers to virtual function tables, which are describedhereinbelow. Virtual inheritance is implemented using pointers tovirtual bases, which are also described hereinbelow.

[0025] It will be shown herein that even though the traditional approachallows some reduction in the overhead of language feature information bysharing between subobjects with repeated inheritance, the overhead canstill be quite high.

[0026] A description of the pointers to virtual function tables will nowbe given. In essence, the traditional layout prescribes that datamembers are laid out “unidirectionally” in an ascending order in memory,so that the data members of each class are laid out consecutively. Also,each object or subobject belonging to a class with virtual functions hasa pointer, referred to as a VPTR, which points to the virtual functiontable (VTBL) of this class. Let us first discuss nonvirtual inheritance.The layout of a base class precedes that of a class derived from it. TheVPTR is commonly laid out at offset zero, which makes it possible forthe VPTR of an object to be shared with one of its directly inheritedsubobjects, so there is in total only one VPTR in the case of singleinheritance.

[0027] However, several VPTRs occur in the case of multiple inheritance,since an object can share a VPTR with only one of its subobjects.Consider, for example, the inheritance hierarchy depicted in FIG. 2,which is a diagram of a class hierarchy illustrating repeatedinheritance (i.e., multiple subobjects of the same type may occur in anobject).

[0028] In this hierarchy, class e inherits from both c and d.Accordingly, the traditional layout of objects of class e has two VPTRs,as illustrated by the object layout chart in FIG. 3.

[0029] Examining FIG. 3 we see that the subobject of class d physicallyencompasses that of class b, which in turn encompasses one subobject ofclass a. All these three subobjects share one VPTR. Similar sharingoccurs between the subobject of class c and the other subobject of classa. There are two subobjects of class a since the inheritance links inFIG. 2 are nonvirtual. Finally, an object of class e does not requireits own VPTR( ), but shares its VPTR( ) with that of subobjects d, b,and a.

[0030] Taking a slightly wider perspective than that of C++, andadopting Eiffel terminology let us call this repeated inheritance. TheEiffel programming language is further discussed by B. Meyer, inObject-Oriented Software Construction, Prentice-Hall, second edition,1997. In the current example, we may say that class a is repeatedlyinherited by class e. A better visual illustration of this fact is givenin FIG. 4, which is the subobject graph of class e of FIG. 2. Thesubobject graph was first introduced by J. Rossie Jr. and D. Friedman,in “An Algebraic Semantics of Subobjects”, Proceedings of the 10^(th)Annual Conference on Object-Oriented Programming Systems, Languages, andApplications (OOPSLA′95), pp. 187-199, Austin, Tex., USA, Oct. 15-191995 (also published in ACM SIGPLAN Notices 30(10) October 1995). Thisgraph captures the containment relationships between subobjects.Evidently, the class a is drawn twice in this figure.

[0031] A description of the pointers to virtual bases will now be given.The traditional layout ensures that in repeated inheritance the offsetof a subobject x is fixed with respect to any other encompassingsubobject y irrespective of the context of y, i.e., the class of theobject in which y itself occurs as a subobject. This is no longer truein the case of non-repeated inheritance, also known as sharedinheritance, which is realized in C++ as virtual inheritance. The offsetof a subobject of a virtual base class is context dependent. In order tolocate such a subobject, be it for the purpose of data members access oran upcast, there is a virtual base pointer (or offset), referred to as a“VBPTR”, stored in each object pointing to the subobject of the virtualbase class. Consider for example the inheritance hierarchy of FIG. 5,which is a diagram of the class hierarchy of FIG. 2, with sharedinheritance (i.e., a class inherited along distinct paths occurs onlyonce in an object). In FIG. 5, classes b and c are virtually derivedfrom class a. In this case, class e has only one subobject of class a.

[0032]FIG. 6 is a subobject graph of class e of FIG. 5. This graph makesit clear that there is only one subobject of class a, which is sharedbetween the subobjects of classes b and c.

[0033] Even though virtual inheritance is a lingual mechanism designedto support a shared variant of multiple inheritance, the C++ semanticsalso allow single virtual inheritance. Thus, the fact that the in-degreeof a class is greater than one in a subobject graph is a necessary butinsufficient condition that the class is a virtual base. This is thereason behind the notational convention of drawing a circle around namesof virtual bases, as was the case with class a in FIG. 6.

[0034]FIG. 7 is a diagram of the memory layout of objects of class e ofFIG. 5, which shows how VBPTRs are used to realize the sharing of aVBPTR between subobjects of classes b and d. Examining FIG. 7, we canalso see that since objects of class d occupy a contiguous memory space,it must be the case that the offset of the subobject of class a withrespect to the data members of d is different in objects of class d thanin objects of class e. Resuming our counting of VPTRs, we see thatobjects of class e have in total three VPTRs: two for the immediateparents of e, c and d; and one for the subobject of the virtual base a.The VPTR of d is also shared with e and b. In contrast, the VPTR of acannot be shared with any of its descendants, since its relative offsetwith respect to these is not fixed.

[0035] As explained above, the offsets to virtual base classes must bestored in memory. In the variant described above these offsets arestored as VBPTRs in each instance of the class. A time penalty isincurred when these pointers are dereferenced for e.g., an upcast, acall to an inherited (even nonvirtual) member function, or in accessinga data member of the virtual base.

[0036] Alternatively, to reduce the space overhead, virtual base offsetsmay be stored in class tables, frequently as special entries in theVTBL. This variant, although more space efficient in the case of manyobjects instantiated from the same class, doubles the time penalty sinceeach access to members of the virtual base must pass through two levelsof indirection instead of one.

[0037] It turns out that for any given class, the number of VBPTRsstored in each object in one variant is exactly the same as the numberof offsets stored in the class information in the other variant. Thus,to facilitate a clear understanding of the present invention asdescribed hereinbelow, the following description will concentrate on the“time-efficient” variant in which pointers to virtual bases are storedin objects.

[0038] The number of VBPTRs is greater than what it might appear atfirst since these pointers cannot be shared across virtual inheritance.To illustrate why this is so, the reader is directed to FIG. 8, which isa diagram of a class hierarchy illustrating single virtual inheritance.Each instance of class u₁ has a virtual base pointer to the v₁subobject. This is also the case for instances of class v₂. Now, sincethe inheritance link between v₂ and u₁ is nonvirtual, then the VBPTR tov₁ can be shared by u₁ and v₂. Also, each instance of class u₂ muststore two pointers to both the v₁ and the v₂ subobjects which correspondto virtual bases. However, as depicted in FIG. 9, which is a diagramillustrating the memory layout of objects of class u₂ of FIG. 8, thepointer to the v₁ base is duplicated in a u₂ instance. That is, there isone such pointer in the memory area allocated for u₂'s own data, butalso another such pointer stored in the v₂ subobject of u₂.

[0039] Let us make the distinction between “essential” and “inessential”VBPTRs. The essential VBPTRs are precisely the minimal set of VBPTRswhich allows direct or indirect access to every virtual subobject fromany of its containing subobjects. Inessential VBPTRs are those which canbe computed from the essential ones, but are stored to ensure that anupcast to an indirect virtual base takes no more time than an upcast toa direct virtual base, thus guaranteeing constant access to all datamembers and all virtual functions. More generally, in the traditionalobject layout scheme, there is no sharing across virtual inheritancelinks of any compiler-generated field, including VPTRs and other fieldsused for realizing run-time type information. Therefore, inessentialVBPTRs are introduced because essential VBPTRs are not shared acrossvirtual inheritance links.

[0040] Alternatively, to reduce space overhead in objects, inessentialVBPTRs could be eliminated. This translates, in our example, to havingonly one VPTR to v₁ that would be stored in the v₂ subobject of u₂. Thismore space efficient variant increases the time to access a virtual basesubobject when a chain of VBPTRs has to be followed. In our example, ifinessential. VBPTRs are eliminated, accessing the v₁ subobject from theu₂ object requires two levels of indirection instead of one.

[0041]FIG. 10 is a diagram of an n-chain virtual inheritance classhierarchy. As shown therein, each instance of the bottom most class in avirtual inheritance chain of n classes must include n(n−1)/2 VBPTRs intotal. The situation is no different if virtual bases are stored withclass information, except that the overhead is not repeated per object.The number of offsets that must be stored in total for all classes is(n³−n)/6, i.e., cubic in the number of classes in the hierarchy!

[0042] Thus, in sum, the feature of multiple inheritance inobject-oriented programming languages causes a significant space andtime overhead for its implementation. Accordingly, it would be desirableand highly advantageous to have methods for reducing the space and timeoverhead associated with implementing multiple inheritance.

SUMMARY OF THE INVENTION

[0043] The present invention is directed to methods for implementingvirtual bases with fixed offsets in object oriented applications.

[0044] In a first aspect of the invention, there is provided a methodfor implementing virtual bases with fixed offsets in a class hierarchygraph corresponding to an object oriented program. The graph has nodesrepresenting object classes and edges representing immediate inheritancetherebetween. The method includes the step of determining whether a setN is empty, the set N including all nodes in the graph. A node x isremoved from the set N, when the set N is not empty. It is determinedwhether a set Y is empty, the set Y including nodes that directly andvirtually inherit from the node x. A return is made to the step ofdetermining whether the set N is empty, when the set Y is empty. A nodey is removed from the set Y, when the set Y is not empty. It isdetermined whether the node y is duplicated in the graph. A return ismade to the step of determining whether the set Y is empty, when thenode y is duplicated. An edge e is replaced with ah edge e′, when thenode y is not duplicated. The edge e represents that the node yvirtually inherits from the node x. The edge e′ represents that the nodex has a fixed offset with respect to the node y. In a second aspect ofthe invention, a return is made to the step of determining whether theset N is empty, upon replacing the edge e.

[0045] In a third aspect of the present invention, there is provided amethod for implementing virtual bases with fixed offsets in a classhierarchy graph corresponding to an object oriented program. The graphhas nodes representing object classes and edges representing immediateinheritance therebetween. The method includes the step of determiningwhether a set V′ is empty, the set V′ including nodes that directly andvirtually inherit from a node v in the graph. A node u is removed fromthe set V′, when the set V′ is not empty. It is determined whether thenode u is duplicated in the graph. The node u is added to a set V, whenthe node u is not duplicated, the set V initially comprising an emptyset of nodes that directly and virtually inherit from the node v andthat are not duplicated. A return is made to the step of determiningwhether the set V′ is empty, upon one of adding the node u and when thenode u is duplicated. It is determined whether the set V is empty. Asubset S of the set V is selected such that the subset S is a maximalindependent set in a set G, when the set V is not empty. The set Gincludes a first ordered pair of the set V and a set E. The set Eincludes a second ordered pair of a node u1 and a node u2. The nodes u1and u2 are included in the set V and have a common descendant in thegraph. It is determined whether the subset S is empty. A node s isremoved from the subset S, when the subset S is not empty. An edge e isreplaced with an edge e′. The edge e represents that the node svirtually inherits from the node v. The edge e′ represents that the nodev has a fixed offset with respect to the node s. In a fourth aspect ofthe present invention, a return is made to the step of determiningwhether the set S is empty, upon replacing the edge e.

[0046] These and other aspects, features and advantages of the presentinvention will become apparent from the following detailed descriptionof preferred embodiments, which is to be read in connection with theaccompanying drawings.

BRIEF DESCRIPTION OF THE DRAWING

[0047]FIG. 1 is diagram illustrating the various graphical notationsused herein with respect inheritance hierarchies, object layout diagramsand subobject graphs;

[0048]FIG. 2 is a diagram of a class hierarchy illustrating repeatedinheritance;

[0049]FIG. 3 is a diagram illustrating the traditional layout of objectsof class e of the hierarchy of FIG. 2;

[0050]FIG. 4 is a subobject graph of a class e of FIG. 2, FIG. 5 is adiagram of the class hierarchy of FIG. 2, illustrating sharedinheritance;

[0051]FIG. 6 is a subobject graph of class e of FIG. 5;

[0052]FIG. 7 is a diagram of the memory layout of objects of class e ofFIG. 5;

[0053]FIG. 8 is a diagram of a class hierarchy illustrating singlevirtual inheritance;

[0054]FIG. 9 is a diagram illustrating the memory layout of objects ofclass u₂ of FIG. 8;

[0055]FIG. 10 is a diagram of an n-chain virtual inheritance classhierarchy;

[0056]FIG. 11 is a block diagram of a computer processing system towhich the present invention may be applied according to an embodiment ofthe present invention;

[0057]FIG. 12 is a flow chart of a method for eliminating transitiveedges in a class hierarchy graph corresponding to an object orientedprogram;

[0058]FIG. 13(a) is a diagram of a class hierarchy;

[0059]FIG. 13(b) is a diagram of the class hierarchy of FIG. 13(a) afterelimination of transitive virtual inheritance edges;

[0060]FIG. 13(c) is a diagram of the class hierarchy of FIG. 13(a) afterelimination of single virtual inheritance;

[0061]FIG. 14 is a diagram of an example hierarchy in which a singleincoming virtual edge which should not be devirtualized;

[0062]FIG. 15 is a flow chart of a method for determining whether a nodey is duplicated in a class hierarchy graph corresponding to an objectoriented program;

[0063]FIG. 16 is a flow chart of a method for determining whether twonodes u and v have a common descendant in a class hierarchy graphcorresponding to an object oriented program;

[0064]FIG. 17 is a diagram of multiple incoming virtual edges, some ofwhich may be devirtualized;

[0065]FIG. 18 is a flow chart of a method for devirtualizing singlevirtual inheritance edges in a class hierarchy graph corresponding to anobject oriented program;

[0066]FIG. 19 is a diagram of the subobject graph of class g in FIG.13(b);

[0067]FIG. 20 is a diagram of the subobject graph of class g in FIG.13(c);

[0068]FIG. 21 is a diagram illustrating inlining a virtual base in thehierarchy of FIG. 5;

[0069]FIG. 22 is a diagram of an n-double-chain shaped virtualinheritance hierarchy;

[0070]FIG. 23 is a flow chart of a method for implementing virtual baseswith fixed offsets in a class hierarchy graph corresponding to an objectoriented program according to an embodiment of the present invention;

[0071]FIG. 24 is a flow chart of a method for implementing virtual baseswith fixed offsets in a class hierarchy graph corresponding to an objectoriented program according to another embodiment of the presentinvention;

[0072]FIG. 25 is a flow chart of a method for streamlining the overallinlining process according to an embodiment of the present invention;

[0073]FIG. 26 is a flow chart of a method which combines two of thethree transformations described herein to streamline the overallinlining process according to an embodiment of the present invention;

[0074]FIG. 27 is a diagram of a hierarchy used to exemplifybidirectional layout according to the present invention;

[0075]FIG. 28 is a diagram illustrating bidirectional layout of class cof FIG. 27;

[0076]FIG. 29 is a diagram of a bidirectional layout of the VTBL ofclass c of FIG. 27;

[0077]FIG. 30 is a flow chart of a method for assigning an initialdirectionality to a subobject n in an object layout chart correspondingto an object class;

[0078]FIG. 31 is a flow chart of a method for randomly assigning adirectionality to a subobject n in an object layout chart correspondingto an object class;

[0079]FIG. 32 is a flow chart of a method for sharing virtual functiontable pointers between virtual subobjects in an object layout chartcorresponding to an object class;

[0080]FIG. 33 is a diagram illustrating the application of both virtualbase inlining and bidirectional layout to class e of the hierarchy ofFIG. 5;

[0081]FIG. 34 is a flow chart of a method for laying out a subobject uin an object layout chart corresponding to an object class according toan embodiment of the present invention;

[0082]FIG. 35 is a flow chart of a method for laying out a subobject uin an object layout chart corresponding to an object class according toanother embodiment of the present invention;

[0083]FIG. 36 is a flow chart of an overall method in which either ofthe procedures bidirectional layout or pairup is performed;

[0084]FIG. 37 is a diagram of a binary tree illustrating multipleinheritance of distinct classes;

[0085]FIG. 38 is a diagram of an interface-implementation classhierarchy;

[0086]FIG. 39 is a diagram of an optimized layout of class c₃ of FIG.38;

[0087]FIG. 40 is a diagram of a double diamond class hierarchy; and

[0088]FIG. 41 is a diagram illustrating an optimized layout of class c₇of FIG. 40.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

[0089] The present invention is directed to methods for implementingvirtual bases with fixed offsets in object oriented applications. Thepresent invention allows shared inheritance (i.e., when a base classinherited along distinct paths occurs only once in the derived class) tobe loosely coupled with its implementation, permitting the compiler tochoose between a number of different strategies for the implementationof shared inheritance so as to minimize the space and time penalties.

[0090] Any language that efficiently implements multiple inheritancemust deal with the issues of time and space overhead. Thus, whileexamples are provided herein corresponding to the C++ programminglanguage so as to facilitate a clear understanding of the presentinvention, the benefits of the present invention apply to any otherstatically typed class-based language. This includes, for example,Eiffel, even though the semantics of multiple inheritance in Eiffel iseven richer than that of C++. The impact of the techniques of thepresent invention is even greater if all inheritance is shared (as it iswith languages such as Theta and Simula). Eiffel is described by B.Meyer, in Object-Oriented Software Construction, Prentice-Hall, secondedition, 1997. Theta is described by A. C. Myers, in “BidirectionalObject Layout for Separate Compilation”, Proceedings of the 10^(th)Annual Conference on Object-Oriented Programming Systems, Languages, andApplications (OOP-SLA′95), pp. 124-139, Austin, Tex., USA, Oct. 15-191995 (also published in ACM SIGPLAN Notices 30(10), October 1995).Simula is described by S. Krogdahl, in “Multiple Inheritance inSimula-Like Languages”, BIT, 25:318-326, 1984.

[0091] Since the methods of the present invention may be utilized in theback-end of a compiler, they are applicable to other semantic models inwhich several implementations are to be amalgamated. An implementationof mixins (a form a multiple inheritance wherein a class can derive frommultiple base classes) in a statically typed programming language, suchas Beta, constitutes a perfect case in point. Beta is described by E.Ernst, in “Propagating mixins”, which is to appear in the Proceedings ofthe 13^(th) European Conference on Object-Oriented Programming(ECOOP′99), Lecture-Notes in Computer Science, Lisbon, Portugal, June1999, R. Guerraoui, ed., Springer Verlag.

[0092] It is to be understood that the present invention may beimplemented in various forms of hardware, software, firmware, specialpurpose processors, or a combination thereof. Preferably, the presentinvention is implemented in software as a program tangibly embodied on aprogram storage device. The program may be uploaded to, and executed by,a machine comprising any suitable architecture. Preferably, the machineis implemented on a computer platform having hardware such as one ormore central processing units (CPU), a random access memory (RAM), andinput/output (I/O) interface(s). The computer platform also includes anoperating system and microinstruction code. The various processes andfunctions described herein may either be part of the microinstructioncode or part of the program (or a combination thereof) which is executedvia the operating system. In addition, various other peripheral devicesmay be connected to the computer platform such as an additional datastorage device and a printing device.

[0093] It is to be further understood that, because some of theconstituent system components and method steps depicted in theaccompanying figures are preferably implemented in software, the actualconnections between the system components (or the process steps) maydiffer depending upon the manner in which the present invention isprogrammed.

[0094]FIG. 11 is a block diagram of a computer processing system 1100 towhich the present invention may be applied according to an embodiment ofthe present invention. The computer processing system 1100 includes atleast one processor (CPU) 1102 operatively coupled to other componentsvia a system bus 1104. A read only memory (ROM) 1106, a random accessmemory (RAM) 1108, a display adapter 1110, an I/O adapter 1112, and auser interface adapter 1114 are operatively coupled to the system bus1104.

[0095] A display device 1116 is operatively coupled to the system bus1104 by the display adapter 1110. A disk storage device (e.g., amagnetic or optical disk storage device) 1118 is operatively couple tothe system bus 1104 by the I/O adapter 1112.

[0096] A mouse 1120 and keyboard 1122 are operatively coupled to thesystem bus 1104 by the user interface adapter 1114. The mouse 1120 andkeyboard 1122 may be used to input/output information to/from thecomputer processing system 1100. A communications adapter 1150 isoperatively coupled to bus 1104 so as to operatively connect system 1100to a network.

[0097] A description of streamlining virtual inheritance according tothe present invention will now be given. Streamlining virtualinheritance consists of three class hierarchy transformations. The firsttransformation is the elimination of transitive virtual inheritanceedges. This transformation brings the hierarchy into a more canonicalform, making it easier to apply the two subsequent transformations whichare space optimization techniques.

[0098] In the second transformation, we devirtualize those virtualinheritance edges which are not used for designating sharing. In thethird transformation, we identify some of the cases where virtualinheritance can be implemented with a fixed offset.

[0099] Although each transformation can be applied to an inheritancehierarchy on its own, the order we chose is the one which maximizestheir combined benefit. However, the order described herein may berearranged, while still maintaining the overall benefits of the presentinvention.

[0100] The first two transformations have been discussed separately inthe literature. We bring these two into synergy here with the inliningmethod of the present invention, while correcting and generalizing apreviously published method for devirtualization. The complexityanalysis of the following procedures are in terms of the class hierarchygraph.

[0101] A description of the method for eliminating transitive virtualinheritance edges will now be given. This transformation simplifies theclass hierarchy. This transformation should, but not must, be appliedprior to any optimization techniques.

[0102] Suppose that class y<_(v)x and z<y. Then, the transitive virtualinheritance edge (z<_(v)x) overspecifies that x is a virtual base of z.In laying out z, it is immaterial whether x is a direct or an indirectvirtual base of z, and therefore we can eliminate the transitive edge (z<_(v)x). This phenomena was first observed by F. Tip and P. Sweeney in“Class hierarchy Specialization”, Proceedings of the Twelfth AnnualConference on Object-Oriented Programming Systems, Languages, andApplications (OOP-SLA′97), Atlanta, Ga., pp. 271-285, October 1997 (alsopublished as ACM SIGPLAN Notices 32(10), 1997). The authors thereof alsoshowed how to remove transitive virtual inheritance edges. The followingprocedure “eliminate-transitive-virtual-edges” illustrates how this isdone.  [1] Procedure eliminate-transitive-edges (Hierarchy H)  [2] Begin [3] For each node χ ε H do  [4] Let S = {y|y

_(v) χ}  [5] For each y, z ε S do  [6] If z < y then  [7] H

H −

z

_(v) χ

 [8] fi  [9] od [10] od [11] end

[0103]FIG. 12 is a flow chart of a method for eliminating transitiveedges in a class hierarchy graph corresponding to an object orientedprogram. The graph has nodes representing object classes and edgesrepresenting immediate inheritance therebetween.

[0104] It is determined if a set V is empty, the set V including thenodes in the graph (step 1202). If the set V is empty , then the methodis terminated (step 1204). On the other hand, if the set V is not empty,then a node x is removed from the set V (step 1206).

[0105] It is then determined if a set V′ is empty, the set V′ includingnodes that directly and virtually inherit from the node x (step 1208).If the set V′ is empty, then a return is made to the step of determiningif the set V is empty (i.e., step 1202) (step 1210). On the other hand,if the set V′ is not empty, then a node y is removed from the set V′(step 1212).

[0106] It is then determined if a set V″ is empty, the set V″ includingthe nodes in the set V′ other than the node y (step 1214). If the set V″is empty, then a return is made to the step of determining if the set V′is empty (step 1216). On the other hand, if the set V″ is not empty,then a node z is removed from the set V″ (step 1218).

[0107] It is then determined if the node y is a base of the node z andnot the node z (step 1220). If the node y is a base of the node z andnot the node z, then an edge e1 is removed from the graph (step 1222).The edge e1 represents that the node z virtually inherits from the nodex.

[0108] On the other hand, if the node y is not a base of the node z oris the node z, then it is determined if the node z is a base of the nodey and not the node y (step 1224). If the node z is a base of the node yand not the node y, then an edge e2 is removed from the graph (step1226). The edge e2 represents that the node y virtually inherits fromthe node x. A return is made to the step of determining if the set V″ isempty (i.e., step 1214), upon one of removing the edge e1 (i.e., step1222), removing the edge e2 (i.e., step 1226), and when the node z isnot a base of the node y (as determined at step 1224).

[0109]FIG. 13(a) is a diagram of a class hierarchy. FIG. 13(b) is adiagram of the class hierarchy of FIG. 13(a) after elimination oftransitive virtual inheritance edges. FIG. 13(c) is a diagram of theclass hierarchy of FIG. 13(a) after elimination of single virtualinheritance as described hereinbelow. Consider the class hierarchy ofFIG. 13(a). Then, the application of the above procedureeliminate-transitive-edges will result in the hierarchy of FIG. 13(b),where the following edges have been removed: (d<_(v)a), (d<_(v)b),(e<_(v)b), and (g<_(v)b). Clearly, global program information is aprerequisite of eliminate-transitive-edges.

[0110] It should be stressed that eliminate-transitive-edges is merely agraph transformation technique, and not a C++ semantic preservingsource-to-source transformation. There are rather subtle semanticdifferences at the source level between FIG. 13(a) and FIG. 13(b). Forexample, if a class x virtually inherits from a base class along twopaths, one of which is protected and the other is private, theneliminating the protected virtual inheritance path will change thesemantics of x. Therefore, this transformation needs to be done afterstatic semantic checking. Conversely, the same example demonstrates arationale for a program to use transitive inheritance edges.

[0111] A description of edge devirtualization will now be given. Edgedevirtualization, which is the next step in the streamlining of virtualinheritance, corresponds to devitalizing those virtual edges in ahierarchy which do not represent shared inheritance. This semanticpreserving transformation is our first space optimization technique.Devirtualizing an edge allows VBPTRs to be eliminated, and it opensopportunities for sharing compiler-generated fields.

[0112] As a simple example, consider a hierarchy with two classes, x andy, where y virtually inherits from x. Then, the edge (y<_(v)x), can bedevirtualized by replacing it with the edge (y<_(r) x) Devirtualizationwas first proposed by D. Bacon, in “Fast and Effective Optimization ofStatically Typed Object-Oriented Languages”, PhD Thesis, U. of Cal. atBerkeley, December 1997. However, determining when it is legitimate isquite an elusive prospect. For example, (y<_(v)x) must not bedevirtualized if two more classes were to be added to our example, toform the hierarchy shown in FIG. 14. FIG. 14 is a diagram of an examplehierarchy in which a single incoming virtual edge which should not bedevirtualized. The reason is that there are two subobjects of type y ina z object, and devirtualizing (y<_(v)x) would also imply two xsubobjects in z, which violates virtual inheritance semantics. Indeed,this is a case where the above referenced devirtualization algorithm ofD. Bacon fails.

[0113] Thus, in contrast to prior belief, a virtual base with a singleincoming edge cannot be devirtualized without a global examination ofthe inheritance hierarchy. Specifically, edge (y<_(v)x) cannot bedevirtualized if y is “duplicated”. Duplication is a global property asshown by the following definition (hereinafter referred to as“definition 1”): a class y is duplicated in a hierarchy H if there aremultiple occurrences of y in the subobject graph of some class z of H.

[0114] There are multiple occurrences of y in z if, for example, zrepeatedly inherits from y “more than once”, or if z inherits from y inboth a repeated and shared manner. Also, y is duplicated if there is yetanother duplicated class u which non-virtually and directly inheritsfrom y. The following procedure (hereinafter referred to as“is-duplicated”) is used to determine whether duplication existsaccording to definition 1 above.  [1] Function is-duplicated (Node y):Boolean  [2] Begin  [3] For each u

_(r) y do  [4] If is-duplicated(u) then  [5] Return true  [6] fi  [7]For each v

y,v ≠ u do  [8] If HCD (u,v) then  [9] Return true [10] fi [11] od [12]od [13] Return false [14] end

[0115]FIG. 15 is a flow chart of a method for determining whether a nodey is duplicated in a class hierarchy graph corresponding to an objectoriented program. The graph has nodes representing object classes andedges representing immediate inheritance therebetween.

[0116] It is determined if a set V is empty, the set V comprising allthe nodes that nonvirtually inherit from the node y (step 1502). If theset V is empty, then the node y is identified as not being duplicated inthe graph (step 1504).

[0117] On the other hand, if the set V is not empty, then a node u isremoved from the set V (step 1506), and it is determined if the node uis duplicated in the graph (step 1508). If the node u is not duplicated,then it is determined if a set V′ is empty (step 1510). The setV′includes all the nodes that directly inherit from the node y exceptfor the node u.

[0118] If the set V′ is empty, then a return is made to the step ofdetermining if the set V is empty (i.e., step 1502) (step 1512). On theother hand, if the set V′ is not empty, then a node v is removed fromthe set V′ (step 1514).

[0119] It is then determined if the node u and the node v have a commondescendant (step 1516). If the node u and the node v do not have acommon descendant, then a return is made to the step of determining ifthe set V′ is empty (i.e., 1510) (step 1518).

[0120] If the node u is duplicated (as determined at step 1508) or thenode u and the node v have a common descendant (as determined at step1516), then the node y is identified as duplicated (step 1520).

[0121] The following procedure (hereinafter referred to as “HCD”) isused to determine whether two classes have a common descendant. [1]Function HCD (Node v₁, v₂): Boolean [2] Begin [3] For each w ε H do [4]If W ≦ v₁, W ≦ v₂, [5] Return true [6] fi [7] od [8] Return false [9]end

[0122]FIG. 16 is a flow chart of a method for determining whether twonodes u and v have a common descendant in a class hierarchy graphcorresponding to an object oriented program. The graph has nodesrepresenting object classes and edges representing immediate inheritancetherebetween. The nodes u and v correspond to classes u and v,respectively.

[0123] It is determined if a set V is empty, the set V comprising allthe nodes in the graph (step 1602). If the set V is empty, then thenodes u and v are identified as not having a common descendant in thegraph (step 1604). On the other hand, if the set V is not empty, then anode w is removed from the set V (step 1606).

[0124] It is then determined if the node w is the node u or the node winherits from the node u, and if the node w is the node v or the node winherits from the node v (step 1608). If the node w is not the node u orthe node w does not inherit from the node u, and the node w is not thenode v or the node w does not inherit from the node v, then a return ismade to the step of determining if the set V is empty (i.e., step 1602)(step 1610). On the other hand, if the node w is the node u or the nodew inherits from the node u, and the node w is the node v or the node winherits from the node v, then the nodes u and v are identified ashaving a common descendant (step 1612).

[0125] Devirtualization can still be done even if there are multipleincoming virtual edges into a virtual base x.

[0126] A single virtual inheritance edge is defined in the followingdefinition (hereinafter referred to as “definition 2”): an edge(y<_(v)x) is considered a single virtual inheritance edge, if y is notduplicated and there is no other y¹=y, y^(1<) ^(v) x, such that there isz, z<y and z<y¹.

[0127] For example, consider the example of FIG. 17, which is a diagramof multiple incoming virtual edges, some of which may be devirtualized.In FIG. 17, (y₂<_(v)x) is the only single virtual inheritance edge. Asingle virtual inheritance edge (y<_(v)x) can be safely devirtualizedsince it's devirtualization preserves the semantics of virtualinheritance.

[0128] For example, class a in FIG. 13(b) has two incoming virtualedges: (b<_(v)a) and (h<_(v)a). Since there are no common descendants tothe nonduplicated nodes b and h, both these edges represent singlevirtual inheritance, and can be devirtualized. Conversely, there are twoincoming virtual edges (d<_(v)c) and (e<_(v)c) into class c. However,singe g is a common ancestor of d and e, these edges are not a case ofsingle virtual inheritance.

[0129] The following procedure (hereinafter referred toas“eliminate-single-VI”) is used to devirtualize all single virtualinheritance edges. This procedure improves on the result of D. Bacon,described in above referenced article “Fast and Effective Optimizationof Statically Typed Object-Oriented Languages”, by considering multipleincoming virtual inheritance edges.  [1] Procedure eliminate-single-VI(Hierarchy H)  [2] Begin  [3] For each node x ε H do  [4] Let S = {y|y

_(v) x

is-duplicated(y)}  [5] For each y ε S do  [6] For each y¹ ε S, y¹ ≠ y do [7] If HCD (y, y¹) then HCD (y, y¹) has shared virtual inheritance withx via subobjects of type y and y¹  [8] next y  [9] fi [10] od A singlevirtual inheritance between y and x was detected [11] H

H −

y

_(v) x

[12] H

H +

y

_(r) x

[13] od [14] od [15] end

[0130]FIG. 18 is a flow chart of a method for devirtualizing singlevirtual inheritance edges in a class hierarchy graph corresponding to anobject oriented program. The graph has nodes representing object classesand edges representing immediate inheritance therebetween.

[0131] It is determined if a set V is empty, the set V comprising allthe nodes in the graph (step 1802). If the set V is empty, then themethod terminates (step 1804). On the other hand, if the set V is notempty, then a node x is removed from the set V, (step 1806).

[0132] It is then determined if a set S is empty, the set S comprisingall of the nodes in the graph that directly and virtually inherit fromthe node x and that are not duplicated in the graph (step 1808). If theset S is empty, then a return is made to the step of determining if theset V is empty (i.e., step 1802) (step 1810). On the other hand, if theset S is not empty, then a node y is removed from the set S (step 1812).

[0133] It is then determined if a set S′ is empty, the set S′ comprisingthe nodes in the set S except the node y (step 1814). If the set S′ isnot empty, then a node y′ is removed from the set S′ (step 1816), and itis then determined if the node y and the node y′ have a commondescendant (step 1818). If the nodes y and y′ do not have a commondescendant, then a return is made to the step of determining if the setS′ is empty (i.e., step 1814) (step 1820). On the other hand, if thenodes y′ and y′ have a common descendant, then a return is made to thestep of determining if the set S is empty (i.e., step 1808). (step1822).

[0134] If the set S′ is determined to be empty at step 1814, then anedge e is replaced with an edge e′ (step 1824) The edge e representsthat the node y directly and virtually inherits from the node x, and theedge e′ represents that the node y has a fixed offset with respect tothe node x. Upon replacing the edge e, a return is made to the step ofdetermining if the set S is empty (i.e., step 1808) (step 1826).

[0135] When procedure eliminate-single-VI is applied to FIG. 13 (b),edges (b<_(v)a), (h<_(v)a), and (f<_(v)d) are devirtualized resulting inthe hierarchy of FIG. 13(c). Consider the subobject graph in FIG. 19,which is a diagram of the subobject graph of class g in FIG. 13(a).There are 6 VPTRs and 10 VBPTRs. After eliminate-single-VI has beenapplied, the number of VPTRs is reduced by one (to 5) and the number ofVBPTRs is reduced by four (to 6),. FIG. 20 is a diagram of the subobjectgraph of class g in FIG. 13(c). In particular, FIG. 20 corresponds tothe subobject graph for class g after eliminate-single-VI has beenapplied to FIG. 13(b).

[0136] Recall the chain of n classes that was presented in FIG. 10.Initially, an object of class a, required n VPTRs and a quadratic numberof VBPTRs. After applying eliminate-single-VI to this chain allinheritance is devirtualized, and an object of class a, requires onlyone VPTR and no VBPTRs.

[0137] The size of a y object may be reduced in a number of differentways due to the devirtualizing of an edge (y<_(v)x). First, theessential VBPTR from y to x is always eliminated. Second, thedevirtualization enables sharing between x and y of compiler generatedfields. These include one VPTR that may be shared between y and x. Evengreater is the saving potential in the inessential VBPTRs from y to thevirtual bases of x, which are all eliminated. There are up to n ofthese.

[0138] In addition, y's savings occurs every time y is a subobject insome object z. There could be an exponential number in n of y subobjectsin an object z. Another kind of potential savings is the inessentialVBPTRs to x in the subobjects derived from y. There are up to n possibleclasses that are derived from y. Each one of these classes has thepotential to have exponential in n number of subobjects derived from y.

[0139] The final class hierarchy transformation, i.e, inlining virtualbases, will now be given. By inlining we mean that instead of storing apointer to a virtual base subobject, this subobject can be stored in afixed offset in the memory layout of the derived class. For an example,let's go back to the subobject graph of FIG. 6. Instead of laying outclass e as in FIG. 7, inlining a into b obtains the layout shown in FIG.21, which is a diagram illustrating inlining a virtual base in thehierarchy of FIG. 5. The new layout eliminates the VBPTR from b to a,and the separate VPTR for a.

[0140] Inlining is similar to devirtualization in thatcompiler-generated fields are eliminated since the offset of a virtualbase is fixed with respect to a derived class. However, unlikedevirtualization, an inlined base may still be shared. In particular,c's subobject in FIG. 21 still retains a VBPTR to a.

[0141] In addition to reducing space overhead, inlining reduces the timerequired to access a virtual base, b, and any of its members from thederived class that the base is inlined into since this derived class nolonger uses a VBPTR to access b.

[0142] The potential savings associated with inlining include those ofdevirtualization. Furthermore, additional inessential VBPTRs may beeliminated. Suppose, for example, that inlining is applied to thehierarchy of FIG. 22, which is a diagram of an n-double-chain shapedvirtual inheritance hierarchy. Assume that a₁ is inlined into a_(i+1)and b₁ is inlined into b_(i+1) for i=1, . . . , n−1. Clearly, asubobject of class a₁ (b₁) does not now need any VBPTRs to a_(j)(b_(j)), j<i. Two VBPTRs, one from a₂ to b₁ and the other from b₂ to a₁,are sufficient for any a_(i) (respectively b_(i)) to access any virtualbase b_(j) (respectively a_(j)) 0<j<i. This is because inlining makesthe offsets of all b_(j) (respectively a_(j)) subobjects fixed withrespect to each other, and in particular, fixed with respect to b₁ (a₁).Therefore, the total number of VBPTRs in objects of class c is reducedfrom (n−1)(n−2) to 2, i.e., from quadratic to a constant.

[0143] Note that neither procedure eliminate-transitive-edges noreliminate-single-VI can eliminate any virtual inheritance from the classhierarchy in FIG. 22, which is a diagram illustrating an n-double-chainshaped virtual inheritance hierarchy. That is, this class hierarchy hasno transitive or single virtual inheritance edges.

[0144] As mentioned above, if x is a virtual base that has an immediateduplicated descendant y then x must not be inlined into y. This isbecause only one virtual base subobject of x occurs in the subobjectgraph while multiple subobjects of y occur. For example, consider theclass hierarchy in FIG. 14. If x were inlined into y which is duplicatedin z, then there would be two subobjects of type x in a z object,contradicting the semantics of virtual inheritance.

[0145] Hereinbelow, two methods are described which implement the inlinevirtual base transformation. The first method is based on the simpleobservation that a virtual base can be inlined into at least one of itsimmediate nonduplicated descendants. Assuming that procedureseliminate-transitive-virtual-edges and eliminate-single-VI were run, asimple procedure (hereinafter referred to as “simple-inline-VB”) forselecting a derived class in which to inline a virtual base according toan embodiment of the present invention follows. [1] Proceduresimple-inline-VB (Hierarchy H) [2] Begin [3] For each node x ε H do [4]If exists y ε H, y

_(v) x and

is-duplicated(y) then [5] H

H −

y

_(v) x

[6] H

H +

y

_(i) x

[7] od [8] end

[0146]FIG. 23 is a flow chart of a method for implementing virtual baseswith fixed offsets in a class hierarchy graph corresponding to an objectoriented program according to an embodiment of the present invention.The graph has nodes representing object classes and edges representingimmediate inheritance therebetween.

[0147] In the method of FIG. 23, it is determined if a set N is empty,the set N including all nodes in the graph (step 2302). If the set N isempty, then the method is terminated (step 2304). On the other hand, ifthe set N is not empty, then a node x is removed from the set N (step2306).

[0148] It is then determined if a set Y is empty, the set Y includingall nodes in the graph that directly and virtually inherit from the nodex (step 2308). If the set Y is empty, then a return is made to the stepof determining if the set N is empty (i.e., step 2302) (step 2310). Onthe other hand, if the set Y is not empty, then a node y is removed fromthe set Y (step 2312).

[0149] It is then determined if the node y is duplicated in the graph(step 2314). If the node y is duplicated, then a return is made to thestep of determining if the set Y is empty (i.e., step 2308) (step 2316).On the other hand, if the node y is not duplicated, then an edge e isreplaced with an edge e′ (step 2318). The edge e represents that thenode y virtually inherits from the node x, and the edge e′ representsthat the node x has a fixed offset with respect to the node y (i.e., thenode x is inlined into the node y). Upon replacing the edge e, a returnis made to the step of determining if the set N is empty (i.e., step2302) (step 2320).

[0150] Procedure simple-inline-VB introduced a new kind of inheritanceedge. In writing y<_(i) x we mean that x is an immediate virtual base ofy and also that x is inlined into The exists statement in proceduresimple-inline-VB is nondeterministic, and it is not clear a priori whichdescendant to inline into. For example, in the subobject graph shown inFIG. 6, a could be inlined into either b or c, but not into both. Itseemed better to inline it into b, since this inlining reduces the sizeof instances of three classes (b, d Land e) as opposed to only twoclasses c and e if the inlining was into c.

[0151] A more powerful version of inlining virtual bases is provided inthe following procedure (hereinafter referred to as “inline-VB”). It isbased on the observation that a virtual base may be inlined into morethan one of its nonduplicated subobjects provided that they do not havea common descendant.  [1] Procedure inline-VB (Node v, Hierarchy H)  [2]Begin  [3] Let V

{u|u

_(v) v

is-duplicated(u)}  [4] Let E

{

u₁, u₂

|u₁, u₂ ε V, HCD (u₁, u₂)  [5] Let G

(V,E)  [6] Select S ⊂ V, S maximal independent set in G  [7] For each sε S do  [8] H

H −

s

_(v) v

 [9] H

H +

s

_(i) v

[10] od [11] end

[0152]FIG. 24 is a flow chart of a method for implementing virtual baseswith fixed offsets in a class hierarchy graph corresponding to an objectoriented program according to another embodiment of the presentinvention. The graph has nodes representing object classes and edgesrepresenting immediate inheritance therebetween.

[0153] It is determined if a set V′ is empty, the set V′ including nodesthat directly and virtually inherit from a node v in the graph (step2402). If the set V′ is not empty, then a node u is removed from the setV′ (step 2404).

[0154] It is then determined if the node u is duplicated in the graph(step 2406). If the node u is duplicated, then a return is made to thestep of determining if the set V′ is empty (i.e., step 2402) (step2408). On the other hand, if the node u is not duplicated, then the nodeu is added to a set V (step 2410). The set V is initially an empty setof nodes that directly and virtually inherit from the node v and thatare not duplicated in the graph. Upon adding the node u to the set V, areturn is made to the step of determining if the set V′ is empty (i.e.,step 2402) (step 2412).

[0155] If set V′ was determined to be empty at step 2402, then it isdetermined if the set V is empty (step 2414). If the set V is not empty,then a subset S of the set V is selected such that the subset S is amaximal independent set in a set G (step 2416). The set G includes afirst ordered pair of the set V and a set E. The set E includes a secondordered pair of a node u1 and a node u2. The nodes u1 and u2 areincluded in the set V and have a common descendant in the graph.

[0156] It is then determined if the subset S is empty (step 2418). Ifthe subset S is not empty, then a node s is removed from the subset S(step 2420), and an edge e is replaced with an edge e′ (step 2422). Theedge e represents that the node s virtually inherits from the node v,and the edge e′ represents that the node v has a fixed offset withrespect to the node s (i.e., the node v is inlined into the node u). Areturn is then made to the step of determining if the subset S is empty(step 2424). If the set V is determined to be empty at step 2414 or thesubset S is determined to be empty at step 2418, then the method isterminated (step 2426).

[0157] To understand the procedure, recall that a set of nodes isindependent in a graph, if no two nodes in it are connected by an edge.The maximal independent set problem finds an independent set thatmaximizes the number of its members. This version of inlining coversedge devirtualization: if an (y<_(v)x) would have been devirtualized byeliminate-single-VI, then in the graph G of inline-VB, node y would haveno edges incident on it, and therefore would be part of the maximalindependent set.

[0158] Unfortunately, the maximal independent set problem is known to beNP (non-deterministic polynomial) complete. This was described by M.Garey and D. Johnson, in Computers and Intractability: A Guide to theTheory of NP-Completeness, W. H. Freeman and Co., 1979. This means thatthe best way, at least to the extent known so far, of finding such a setis not significantly better than trying out all possible different setsS. Although this exponential computation time sounds deterring,inline-VB may be feasible in many cases, since it is exponential only inthe number of immediate virtual descendants, which could be a smallnumber in practice.

[0159] A description of how the transformations presented above can becombined together into two cohesive procedures will now be given. Forany such procedure, eliminate-transitive-edges should always be appliedfirst to a class hierarchy before either edge devirtualization orinlining. To see this, consider the transitive edge (a<_(v)d) in FIG.13(a). Eliminate-transitive-edges enables eliminate-single-VI, sinceonly after the transitive edge (a<_(v)d) is eliminated, can (a<_(v)b) bedevirtualized. Eliminate-transitive-edges eliminates inferior inliningcandidates. Inlining a into d attains the same benefits or less thaninlining a into b and, therefore, is inferior. But (a<_(v)d) is atransitive edge. Procedures eliminate-transitive-edges andeliminate-single-VI should be executed before simple-inline-VB to ensurethat only shared bases are inlined.

[0160]

[0161] There are two natural ways to combine the above transformations.The first is provided in the following procedure (hereinafter referredto as “streamline-VI”), which has an overall execution time bounded bythe complexity of eliminate-single-VI. [1] Procedure streamline-VI(Hierarchy H) [2] Begin [3] eliminate-transitive-edges (H) [4]eliminate-single-VI (H) [5] simple-inline-VB (H) [6] end

[0162]FIG. 25 is a flow chart of a method which combines the three abovetransformations (procedures) to streamline the overall inlining processaccording to an embodiment of the present invention. First, theprocedure eliminate-transitive-edges is performed (step 2502). Next, theprocedure eliminate-single-VI is performed (step 2504). Lastly, theprocedure simple-inline-VB is performed (step 2506).

[0163] The second is provided in the following procedure (hereinafterreferred to as “streamline-VIA”), which has an overall execution timebounded by the complexity of inline-VB. Since inline-VB will inlinesingle virtual inheritance edges, eliminate-single-VI is not needed instreamline-VIA. [1] Procedure streamline-VIA (Hierarchy H) [2] Begin [3]eliminate-transitive-edges (H) [4] For each node n in H do [5] inline-VB(n, H) [6] od [7] end

[0164]FIG. 26 is a flow chart of a method which combines two of thethree above transformations (procedures) to streamline the overallinlining process according to an embodiment of the present invention.First, the procedure eliminate-transitive-edges is performed (step2602). Lastly, the procedure inline-VB is performed (step 2604).

[0165] Both the elimination of transitive inheritance edges and edgedevirtualization or inline-VB are needed to remove the circle notationwhich identifies shared bases in a class hierarchy. The application ofthese procedures makes the circle notation for virtual classes insubobject graphs redundant. Nevertheless, we retain circle notationbecause it highlights virtual bases. If these procedures have beenapplied, then shared bases are exactly those nodes in the subobjectgraph whose in-degree is greater than one.

[0166] Of the three transformations presented, only eliminate-single-VIis a source-to-source transformation. As noted above,eliminate-transitive-edges must be applied after static semanticchecking of the program. Simple-inline-VB and inline-VB must beperformed on an intermediate representation of the application as thereis no analogous language construct with which to represent inlinedinheritance. Therefore, either version of streamline-VI may be appliedto an application's intermediate representation.

[0167] The decision of whether streamline-VI should be invoked whenwhole program information is available is not a hard one. The procedurestreamline-VI will never increase the execution-time or memoryconsumption of an application. Moreover, the run-time of the first twotransformations and the simple-inline-VB are only polynomial. Therun-time of inlining-VB depends on the extent of the optimization thatis applied. There are, however, good heuristics for the maximalindependent set that run in polynomial time.

[0168] Systems providing whole program information include the IBMVisual Age C++ compiler and Vortex. The former is described by M.Karasick, in “The Architecture of Montana: An Open and ExtensibleProgramming Environment with an Incremental C++ Compiler”, ProceedingsFoundations of Software Engineering (FSE′98), Orlando, Fla., November1997; and L. Nackman and J. Barton, in “Base-Class Composition withMultiple Derivation and Virtual Bases”, Proceedings of the Sixth UsenixC++ Technical Conference, 1994. Vortex is described by C. Chambers, J.Dean, and D. Grove, in “Whole-Program Optimization of Object-OrientedLanguages”, Technical Report UW-CSE-96-06-02, U. of Wash., Dept. ofComputer Science and Engineering, June 1996.

[0169] A description of bidirectional layout techniques according to thepresent invention will now be given. FIG. 27 is a diagram of a hierarchyused to exemplify bidirectional layout according to the presentinvention. Given the inheritance hierarchy of FIG. 27, the traditionalobject layout scheme requires only one VPTR for all the classes, exceptfor class c which requires two VPTRs.

[0170]FIG. 28 is a diagram illustrating bidirectional layout of class cof FIG. 27. We can layout class c using only one VPTR as shown.

[0171] Suppose that class a₁, is laid out using negative offsets. Thatis to say, its VPTR will be at offset zero, and all its data members,user-defined and compiler-generated (other than its VPTR), are laid outin decreasing addresses. This will force what we may call a negativedirectionality on all classes a₁, . . . , a₉. Similar layout is imposedon the VTBL: functions associated with classes a₁, . . . , a₉ willoccupy entries −1, −2, . . . in their table. Classes b₁, . . . , b₉ willstill have a positive directionality, with their entries at offsets 0,1, . . . in their VTBL. Classes a₉ and b₅ are married in class c: theyshare their VPTR as illustrated in FIG. 29, which is a diagram of abidirectional layout of the VTBL of class c of FIG. 27.

[0172] In addition to marrying subobjects that are inherited and haveopposite directionality, subobjects that are fields of an object mayalso be married if they have opposite directionalities; that is, onefield has positive directionality and the other field has negativedirectionality.

[0173] Consider a class A that has two fields F1 and F2, such that F1has type class B and F2 has type class C. If the directionality of classB and class C are opposite, then F1 and F2 can be married and share avirtual function table pointer in an A object. This sharing ispersistent; that is, F1 and F2 will continue to share a virtualfunctional table pointer when class A is further derived.

[0174] Finally, if classes A and B have opposite directionality, thenthe run-time system could marry an object of type A and an object oftype B together to share a virtual function table pointer when objectsof these class types are allocated.

[0175] The directionality of a class x is denoted by χ^((x)). In thetraditional layout, χ^((x))=positive for all x. With bidirectionallayout, χ^((x)) can be either positive or negative. If this is the case,then we say that x is “directed”.

[0176] Two more values which χ^((x)) can assume are mixed and none.Mixed is used if x shares its VPTR with two base classes that aremarried with each other. None occurs if x and all of its base classeshave no virtual functions and consequently x has no need for a VPTR. Inboth cases we will say that x is undirected. The predicateχ^((x))=−χ^((y)) means that either χ^((x))=positive and χ^((y))=negativeor that χ^((x))=negative and χ^((y))=positive. The semantics of thedifferent values of χ^((x)) are summarized in Table 1. TABLE 1 χ^((X))^(a) ^(b) ^(c) ^(d) positive yes no yes 0, 1, . . . negative yes yes no−1, −2, . . . mixed yes yes yes . . . , −2, −1, 0, 1, . . . none no noyes none

[0177] The notations used in FIG. 1 are as follows:

[0178] a: a VPTR at offset zero

[0179] b: data members in negative offsets

[0180] c: data members in positive offsets

[0181] d: indices of VTBL entries

[0182] In order for bidirectional layout to work in a separatecompilation setting, we need an oracle to assign the rightdirectionalities to classes a₁, and b₁, when they are compiled, whichcould be prior to the compilation of class c. A simple and effectivework around is to assign directionalities at random.

[0183] The following procedure (hereinafter referred to as“assign-initial-directionality”) may be used to assign directionalitiesto classes whose directionality is not determined by their parents. Thiswill insure that with probability 0.5, one VPTR will be saved in classc. We can say that the expected savings is 0.5·1=0.5 VPTR. [1] Procedureassign-initial-directionality (Node n) [2] Begin [3] If n has no virtualfunctions then [4] χ^((n))

none [5] Else [6] χ^((n))

Random(n) [7] fi [8] end

[0184]FIG. 30 is a flow chart of a method for assigning an initialdirectionality to a subobject n in an object layout chart correspondingto an object class. The chart includes subobjects of the object classand virtual function table pointers for pointing to virtual functiontables of the subobjects.

[0185] It is determined if the subobject n has any corresponding virtualmethods (step 3002). If the subobject n does not have any correspondingvirtual methods, then no directionality is assigned to the subobject n(step 3004). On the other hand, if the subobject n has any correspondingvirtual methods, then a random directionality is assigned to thesubobject n (step 3006).

[0186] The crucial point in computing this expectation is that the“coin-tosses” in a₁, and b₁ were independent. More generally, anexpected savings can be guaranteed if any two selections ofdirectionalities to root classes are independent. It is not necessaryhowever to have independence between any three selections. To implement“pair-wise-independence” random selection we can apply a standardtechnique of randomized algorithms, such as that described by L. Carterand M. Wegman, in “Universal Classes of Hash Functions”, J. Comput. Sys.Sci., 18:143-154, 1979, and then replace the coin tosses by a hashfunction. In other words, whenever a compiler encounters a class whosedirectionality is not forced, it applies a hash function, selected atrandom from a universal class of such functions, to its name. The valueof the hash function determines whether the class has positive ornegative directionality. Thus, we will use the following procedure(hereinafter referred to as “random”) as a pseudo random-numbergenerator. That is, the procedure random will be used to return thepseudo-random directionality assignment of a class. [1] Function random(Noden) [2] Begin [3] If odd (hash(n)) then [4] Return positive [5] else[6] Return negative [7] fi [8] end

[0187]FIG. 31 is a flow chart of a method for randomly assigning adirectionality to a subobject n in an object layout chart correspondingto an object class. The chart includes subobjects of the object classand virtual function table pointers for pointing to virtual functiontables of the subobjects.

[0188] A hash function is applied to the subobject n such that aresponse of odd or not odd is returned (step 3102). It is thendetermined if the response of odd is returned (step 3104). If theresponse of odd is returned, then the directionality of the subobject nis identified as positive (step 3106). On the other hand, if theresponse of not odd is returned, then the directionality of thesubobject n is identified as negative (step 3108).

[0189] One major advantage of a hash function compared to coin-tosses isthat, once it has been selected, its values can be reproduced inindependent runs of the compiler.

[0190] A description of the “ephemeral marriage” of virtual basesaccording to an embodiment of the present invention will now be given.The phrase “ephemeral marriage” is hereinafter used to refer to the casewherein two virtual subobjects laid out in opposite directions in anobject layout chart share the same virtual function table pointer. Anephemeral marriage is not persistent, in contrast to “persistentmarriage” described hereinbelow.

[0191] The use of indirection in the implementation of virtual basesubobjects makes it possible to place them anywhere in memory. Thisdegree of freedom, together with bidirectional layout, unfolds savingopportunities beyond those suggested by our motivating example. Let v₁and v₂ be two virtual bases, direct or indirect, of class u, and supposethat χ^((v1))=positive and χ^((v2))=negative. Then, between v₁ and v₂ wecould save one VPTR, by placing them against each other in the layout ofu. We say that v₁ and v₂ are married in u, but in contrast with themarriage of nonvirtual base classes a₉ and b₅, this marriage isephemeral. Subobjects v₁ and v₂ are not necessarily married with eachother in every context in which they occur together. In other words,even though the subobjects of v₁ and v₂ are adjacent in objects of classu, they are not necessarily adjacent if u occurs as a subobject ofanother class w, w<u. Therefore, it is necessary that u maintains twoVBPTRs, one for v₁ and one for v₂.

[0192] The following procedure (hereinafter referred to as“ephemeral-virtual-base-marriage”) is used to provide an ephemeralmarriage of virtual bases. The procedure allows for a class to betemporarily married with one of its parents.  [1] Procedureephemeral-virtual-base-marriage (Node u)  [2] Begin  [3] Let V

{v|u

_(v) v}  [4] If χ^((u)) = positive

χ^((u)) = negative then  [5] V

V U {u}  [6] fi  [7] Let V⁺

{v ε V|χ^((v)) = positive}  [8] Let V⁻

{

v ε V|χ^((v)) = negative} Marry unmarried virtual bases  [9] While V⁺ ≠Ø

V⁻ ≠ Ø do [10] Select v₁ ε V⁺ and v₂ ε V⁻ [11] Marry v₁ and v₂ [12] V⁺

V⁺ − v₁ [13] V−

V⁻ − v₂ [14] od [15] end

[0193]FIG. 32 is a flow chart of a method for sharing virtual functiontable pointers between virtual subobjects in an object layout chartcorresponding to an object class. The virtual function table pointerspoint to virtual function tables of the subobjects.

[0194] It is determined if a directionality of a subobject u is one ofpositive and negative (step 3202). The subobject u is added to a set V,when the directionality of the subobject u is one of positive andnegative (step 3204). The set V includes nodes that are direct virtualbases of the subobject u. The set V also includes the subobject u, ifthe subobject u is directed.

[0195] Upon adding the subobject u to the set V or if the directionalityof the subobject u is not one of positive and negative (as determined atstep 3202), then it is determined if one of sets V+and V−is empty (step3206). The set V+includes subobjects in the set V having positivedirectionality, and the set V−includes subobjects in the set V havingnegative directionality.

[0196] If one of the sets V+and V−is empty, then the method isterminated (step 3208). On the other hand, if both of the sets V+andV−are not empty, then a subobject v1 is removed from the set V+(step3210), and a subobject v2 is removed from the set V−(step 3212). Thesubobject v1 is married to the subobject v2 (i.e., the subobject v1 andthe subobject v2 share a virtual function table pointer)(step 3214), anda return is made to the step of determining if one of the sets V+andV−is empty (i.e., step 3206.) (step 3216).

[0197] The procedure assumes that a directionality was already assignedto the class and to all of its parents. In particular, the procedure isexpected to be executed after the procedure (presented below) thatpersistently marries nonvirtual bases.

[0198] Consider again the hierarchy of FIG. 5. Suppose thatχ^((a))=positive and that χ^((e))=negative. Then, procedureephemeral-virtual-base-marriage improves further the layout of FIG. 21obtaining the layout of FIG. 33, which is a diagram illustrating theapplication of both virtual base inlining and bidirectional layout toclass e of the hierarchy of FIG. 5. Advantageously, the layout of FIG.33 uses only one VPTR and one VBPTR. Moreover, notice that, unlikenon-virtual inheritance, if the virtually derived classes of a base aredirected, their directionalities may be different.

[0199] The marriage of two virtual bases requires that their VTBLs arejuxtaposed. Since, in general, a class has a different VTBL for everycontext this class is used, marriage incurs no additional overhead. Whenclasses v₁ and v₂ are married in u, we also place the VTBL of v₁ classin a u context against the VTBL of v₂ in a u context. If the VTBL of,for example, v₁ in a u context happens to be exactly the same as that ofa derived class of u, w, then the marriage of v₁ may make it impossibleto optimize class space by using only one VTBL for v₁ in w and for v₁ inu.

[0200] A description of “persistent marriage” of nonvirtual bases willnow be given. The phrase “persistent marriage” is hereinafter used torefer to the case wherein, in an, object layout chart of an object x,two nonvirtually inherited subobjects laid out in opposite directionsshare the same virtual function table pointer and continue to share thesame virtual function table pointer when x is further derived.

[0201] Let us now proceed to the description of bidirectional layout fornonvirtual bases. Let us assume inductively that a directionality wasassigned to all classes from which a class u inherits, and that allthese classes were laid out already. The questions are then how should ube laid out, what kind of sharing of VPTRs will u have with its parents,and what should χ^((u)) be. The following procedure (hereinafterreferred to as “bidirectional-layout”) answers these questions, bydetailing how the nonvirtual bases of u are married together in u.  [1]Procedure bidirectional-layout (Node u)  [2] Begin  [3] Let V

{v|u

_(r) v

u

_(i) v}  [4] Case |V| of  [5] 0: //u is a root  [6]assign-initial-directionality (u)  [7] 1: //u has exactly one parent [8] Let v be the single parent of u  [9] If χ^((v) =) none then [10]assign-initial-directionality(u) [11] else [12] χ^((u))

χ^((v)) [13] Share a VPTR with v. [14] fi [15] 2: //u has exactly twoparents [16] Let v₁ and v₂ be the two parents of u [17] If χ^((v1) =)χ^((v2)) = none then [18] assign-initial-directionality(u) [19] else ifχ^((v1) =) −χ^((v2)) then // a VPTR is saved in the layout of u [20]χ^((u))

mixed [21] Marry v₁ and v₂ [22] Share VPTR with v₁ //wlog could sharewith v₂ [23] else if exists i, i = 1, 2 s.t. v_(i) is directed then [24]χ^((u))

χ^((v)i⁾ [25] Share a VPTR with v_(i) [26] else   // one parent ismixed, the other is mixed or none [27] Let v_(i) be a parent of u thatis mixed [28] χ^((u))

mixed [29] Share a VPTR with v_(i) [30] fi [31] Otherwise: //u has morethan two parents [32] pairup(u) [33] esac [34] end

[0202]FIG. 34 is a flow chart of a method for laying out a subobject uin an object layout chart corresponding to an object class. The chartincludes subobjects of the object class and virtual function tablepointers for pointing to virtual function tables of the subobjects.

[0203] It is determined if a set V is empty, the set V comprisingsubobjects that have a fixed offset with respect to the subobject u andthat are directly inherited from the subobject u (step 3402). If the setV is empty, then an initial directionality is assigned to the subobjectu (step 3404).

[0204] If the set V is determined to not be empty at step 3402, then itis determined if the set V has only one member (step 3406). If the set Vhas only the one member, then it is determined if a directionality of asubobject v in the set V is unassigned (step 3408). In this case, thesubobject v is a single parent subobject of the subobject u.

[0205] If the directionality of the subobject v is unassigned, then aninitial directionality is assigned to the subobject u (step 3410). Onthe other hand, if the directionality of the subobject v is assigned,then the directionality of the subobject v is assigned to the subobjectu and a virtual function table pointer is shared between the subobjectsv and u (step 3412).

[0206] If the set V is determined to not have only the one member atstep 3406, then it is determined if the set V has only two members (step3414). If the set V has only the two members, then it determined ifdirectionalities of subobjects v1 and v2 in the set V are unassigned(step 3416). In this case, the subobjects v1 and v2 are both parentsubobjects of the subobject u.

[0207] If the directionalities of the subobjects v1 and v2 are assigned,then it is determined if the directionalities of the subobjects v1 andv2 are opposing (step 3418). Opposing is intended to mean that one ofthe subobjects v1 and v2 is positive and the other is negative.

[0208] If the directionalities of the subobjects v1 and v2 are notopposing, then it is determined if any of the subobjects v1 and v2 aredirected (step 3420). Directed is intended to mean either positive ornegative, but not mixed. If any of the subobjects v1 and v2 are notdirected, then the directionality of the subobject u is assigned asmixed (step 3422) and a virtual function table pointer is shared betweenthe subobject u and any one of the subobjects v1 and v2 that is mixed(step 3424). In this case, one parent of u has mixed directionality.

[0209] If the directionalities of the subobjects v1 and v2 in the set Vare determined to be unassigned at step 3416, then an initialdirectionality is assigned to the subobject u (step 3426).

[0210] If the directionalities of the subobjects v1 and v2 aredetermined to be opposing at step 3418, then the directionality of thesubobject u is assigned as mixed (step 3428). Moreover, the subobject v1is married to the subobject v2 and a virtual function table pointer isshared between the subobject u and one of the subobjects v1 and v2 (step3430).

[0211] If any of the subobjects v1 and v2 are determined to be directedat step 3420, then the directionality of any of the directed subobjectsis assigned to the subobject u (step 3432). Moreover, a virtual functiontable pointer is shared between the subobject u and the subobject v1 orv2 that is directed (step 3434).

[0212] If it is determined that the set V does not have only the twomembers at step 3414, then the procedure pairup is performed (step3436).

[0213] The method is terminated (step 3438), upon performing any one ofsteps 3404, 3410, 3412, 3424, 3426, 3430, 3434, and 3436.

[0214] The cases in procedure bidirectional-layout in which u has noparents, only one parent, or two parents which both have the samedirectionality are rather pedestrian. The case where χ^((v1))=−χ^((v2))is the most interesting one since it is the only case in which a VPTR issaved. Note that the procedure favors a none directionality for u.However, as in the vast majority of cases, this is not possible, ittries to make u directed, in order to leave open future optimizationopportunities. Class u is assigned a mixed directionality only if thereis no other choice.

[0215] When u has more than two parents, the above procedurebidirectional-layout calls the following procedure hereinafter referredto as “pairup”. Procedure pairup simply generalizes the breakdown intodifferent cases in bidirectional-layout when u has two parents. In oneembodiment of the present invention, the procedure pairup could be usedto completely replace the procedure bidirectional-layout.  [1] Procedurepairup(Node n)  [2] Begin  [3] Let V

{v|n

_(i) v

n

_(r) v}  [4] Let V⁺

{v ε V|χ^((v)) = positive}  [5] Let V⁻

{

v ε V|χ^((v)) = negative}  [6] Let V°

{v ε V|χ^((v)) = none}  [7] Let V*

{v ε V|χ^((v)) = mixed} Marry pairs of opposite direction bases that arenot yet married.  [8] While V⁺ ≠ Ø

V⁻ ≠ Ø do  [9] Select v₁ ε V⁺, _(v2) ε V⁻ [10] Marry v₁ and v₂ [11] V⁺

V⁺− v₁ [12] V⁻

V⁻− v₂ [13] od Assign directionality to n and determine sharing [14] IfV⁺ ≠ Ø then [15] X^((n))

positive [16] Share a VPTR with v ε V⁺ [17] else if V⁻ ≠ Ø then [18]χ^((n))

negative [19] Share a VPTR with v ε V⁻ [20] else if V* ≠ Ø then [21]χ^((n))

mixed [22] Share a VPTR with v ε V* [23] else if v ε V

χ^((v)) = positive then [24] χ^((n))

mixed [25] Share a VPTR with v [26] else //only V° ≠ Ø [27]assign-initial-directionality(n) [28] fi [29] end

[0216]FIG. 35 is a flow chart of a method for laying out a subobject uin an object layout chart corresponding to an object class according toanother embodiment of the present invention. The chart includessubobjects of the object class and virtual function table pointers forpointing to virtual function tables of the subobjects.

[0217] It is determined if one of sets V+and V−is empty (step 3502). Theset V+includes subobjects in a set V having positive directionality. Theset V−includes subobjects in the set V having negative directionality.The set V includes subobjects that have a fixed offset with respect tothe subobject u and are directly inherited from the subobject u.

[0218] If both of the sets V+and V−are not empty, then a subobject v1 isremoved from the set V+(step 3504), and a subobject v2 is removed fromthe set V−(step 3506). The subobject v1 is married to the subobject v2(i.e., the subobject v1 and the subobject v2 share a virtual functiontable pointer) (step 3508), and a return is made to the step ofdetermining if one of the sets V+and V−is empty (step 3510).

[0219] On the other hand, if one of the sets V+and V−is empty (asdetermined at step 3502), then it is determined if the set V+is empty(3512). If the set V+is not empty, then a positive directionality isassigned to the subobject u and a virtual function table pointer isshared between the subobject u and a subobject v in the set V+(step3514).

[0220] On the other hand, if the set V+is empty, then it is determinedif the set V−is empty (step 3516). If the set V−is not empty, then anegative directionality is assigned to the subobject u and a virtualfunction table pointer is shared between the subobject u and a subobjectv−in the set V−(step 3518). On the other hand, if the set V−is empty,then it is determined if a set V* is empty (step 3520). The set V*includes subobjects in the set V having mixed directionality. If the setV* is not empty, then a mixed directionality is assigned to thesubobject u and a virtual function table pointer is shared between thesubobject u and a subobject v* in the set V* (step 3522). If the set V*is empty, then it is determined whether there exists a subobject v inthe set V having a positive directionality (step 3524). If so, then amixed directionality is assigned to the subobject u and a VPTR is sharedbetween the subobjects u and v (step 3526). Otherwise, an initialdirectionality is assigned to the subobject u (step 3528). The method isterminated upon performing any one of steps 3514, 3518, 3522, 3526, and3528 (step 3530).

[0221]FIG. 36 is a flow chart of an overall method in which either ofthe procedures bidirectional layout or pairup is performed. Atopological ordering is assigned to all nodes in a set V, the set Vincluding subobjects in the chart (step 3602). The nodes of a directedgraph are topologically ordered if each node has a number whose value isgreater than the values of its parents' numbers. It is then determinedif the set V is empty (step 3604). If the set V is empty, then themethod is terminated (step 3608). On the other hand, if the set V is notempty, then a node u is removed from the set V in topological order(step 3610).

[0222] Next, either the procedure bidirectional-layout or the procedurepairup is performed (step 3612). Then, the procedure ephemeral marriageis performed (step 3613). A return is then made to the step ofdetermining whether the set V is empty (i.e., step 3604) (step 3614).

[0223] Up to now, the marrying of subobjects that are inherited and haveopposite directionalities has been described. However, the abovetechniques also apply to subobjects that are fields.

[0224] Consider a class A that has two fields F1 and F2, such that F1has type class B and F2 has type class C. If the directionality of classB and class C are opposite, then F1 and F2 can be married and share avirtual function table pointer in an A object. This sharing ispersistent; that is, F1 and F2 will continue to share a virtualfunctional table pointer when class A is further derived.

[0225] Finally, if classes A and B have opposite directionality, thenthe run-time system could marry an object of type A and an object oftype B together to share a virtual function table pointer when objectsof these class types are allocated.

[0226] To illustrate the potential reduction in space overhead that ourtechniques can achieve, we introduce, in FIGS. 37, 38 and 40, threecanonical ways that multiple inheritance may be used.

[0227] The canonical examples presented hereinafter and their variantsare typical of the way that applications use multiple inheritance.Therefore, we expect that savings, similar to what we have found in ourexamples, will also be found in real applications.

[0228]FIG. 37 is a diagram of a binary tree illustrating multipleinheritance of distinct classes. In the traditional memory layoutscheme, an object of class c₁₅ requires a total of 8 VPTRs. Each nodecan share its VPTRs with, at most, one base class. A lucky assignment ofdirectionalities to classes c₁, . . . , c₈ would reduce that number toas little as 4, which represents a 50% reduction in the compilergenerated fields.

[0229] If all inheritance links in FIG. 37 were virtual then thetraditional model requires 49 compiler-generated fields: 15 VPTRs (onefor each class as no sharing is allowed), and 34 VBPTRs (20 of which areinessential). Applying procedure eliminate-single-VI, followed byprocedure bidirectional layout, may bring this number down to four.

[0230]FIG. 38 is a diagram of an interface-implementation classhierarchy. The hierarchy represents a typical use of shared inheritanceto model programming with interfaces. This is further described by L.Nackman and J. Barton, in “Base-Class Composition with MultipleDerivation and Virtual Bases”, The C++ Conference, pp. 57-71, Cambridge,Mass., April 1994; and A. Myers, in “Bidirectional Object Layout forSeparate Compilation”, Proceedings of the 10^(th) Annual Conference onObject-Oriented Programming Systems, Languages, and Applications(OOP-SLA′95), pp. 124-139, Austin, Tex., USA, Oct. 15-19 1995 (alsopublished in ACM SIGPLAN Notices 30(10), October 1995). The inheritancehierarchy forms a ladder (in this instance with three steps) where thereis an implementation inheritance of c₁, c₂ and c₃ and an interfaceinheritance of i₁, i₂ and i₃ such that the inheritance betweenimplementations and interfaces, and interfaces and interfaces isvirtual. The shared inheritance prevents an interface from beingrepresented multiple times in an object of any derived class. In thetraditional memory layout scheme, the overhead of multiple inheritancean object of class c₃ requires is 10 compiler generated fields (4 VPTRsand 6 VBPTRs). The one inessential VBPTR points from i₃ to i₁.

[0231] The methods of the present invention reduce this overhead by 80%to 2 compiler-generated fields: one VPTR and one VBPTR. The layout whichachieves this is depicted in FIG. 39, which is an optimized layout ofclass c₃ of FIG. 38. The layout was obtained by inlining i₁ and i₂,inlining i₂ and i₃, and assigning X^((i1))←negative, X^((c1))←positive.Incidentally, this layout is very similar to the bidirectional optimizedlayout proposed by A. Meyers for the Theta programming language in theabove referenced article entitled “Bidirectional Object Layout forSeparate Compilation”. The differences are that the layout optimizationtechniques of the present invention are general purpose, whereas thesemantics of multiple inheritance in Theta is that only singleinheritance is allowed for implementation inheritance.

[0232] Finally, FIG. 40 presents a portion of the class hierarchy of theC++ standard I/O library. In particular, FIG. 40 illustrates a doublediamond class hierarchy.

[0233] In the tradition memory layout scheme, an object of class c₇ has11 compiler-generated fields: 5 VPTRs and 6 VBPTRs. The two inessentialVBPTRs point from c₅ and c₆ to Applying our techniques we see that c₇can be laid out using only 4 compiler-generated fields. That is, 2 classtable points and 2 virtual base pointers as illustrated in FIG. 41,which is a diagram illustrating an optimized layout of class c₇ of FIG.40.

[0234] This 63% reduction is made possible by the following optimizationsteps:

[0235] (1) Inlining c₁ to c₃. This step represents a saving of fourcompiler generated fields: one VPTR (due to the sharing of a VPTRbetween c₃ and c₁); one essential VPTR, pointing from c₃ to c₁; and twoinessential VPTRs, pointing from c₅ and c₆ to c₁.

[0236] (2) Inlining c₄ and c₆. This step makes it possible to share aVPTR between c₄ and c₆, and to eliminate the essential VBPTR from c₆ toc₄ for a total saving of two compiler generated fields. Note that wecould also have attributed to this step the saving of the twoinessential VBPTRs, which were accounted for in the previous step.

[0237] (3) Assigning directionalities to classes.

[0238] In particular, we have assigned X^((c1))←positive, which imposedthe same directionality on classes c₃, c₄, c₆ and c₇. We also assignedX^((c2))←negative and X^((c5))←negative. This made it possible to marryc₂ and c₃ in c₄ thereby saving one more VPTR.

[0239] The frugal object layout of FIG. 41 looks even more impressivewhen considering that it also implements the hierarchy in which allinheritance links in FIG. 40 are made virtual. In this hierarchy, whichrepresents a typical use of shared inheritance for extendibleframeworks, the tradition model requires 26 compiler-generated fieldsfor an object of class c₇: 7 VPTRs, one for each class, and 19 VBPTRs,out of which 8 are essential.

[0240] Table 2 summarizes the savings provided by the optimizationtechniques of the present invention in each of the major hierarchyexamples used thus far herein. TABLE 2 Example FIG. # ^(a) ^(b) Diamond5 5 2 Binary Tree 35 8 4 Virtual Binary Tree 35 49 4 Interface 36 10 2Implementation Double Diamond 38 11 4 Virtual Double 38 26 4 DiamondVirtual n-Chain 10 n + (((n − 1) (n − 2))/2) 1 Virtual n-Double 21 n² −n + 2 2n − 1 Chain

[0241] Our optimization techniques were based on two principal ideas:the inlining of virtual bases whose primary savings is in the number ofVBPTRs, and bidirectional object layout which gives rise to a savings inthe number of VPTRs. Inlining of virtual bases required preprocessing byelimination of transitive edges. Two procedures were provided above forinlining virtual bases according to the present invention. The simpleprocedure (simple-inline-VB) is guaranteed to run in polynomial time andis practice expected to run in O(n²). This procedure should be run intandem with devirtualization. The more sophisticated procedure(inline-VB) has an exponential running time, although the fact thatinheritance hierarchies tend to be sparse graphs gives reasons tobelieve that in practice this time reduces to polynomial. Thesophisticated procedure subsumes our devirtualization procedure (which,in turn, corrected a previous misconception).

[0242] Bidirectional layout, which can be run in a separate compilationenvironment, comes in two varieties. The first variety, which we calledephemeral marriage of virtual bases is targeted at the shared variant ofmultiple inheritance.

[0243] The potential impact of these techniques was demonstrated using aset of canonical examples. We have seen that a significant reduction inobject space is made possible by their application.

[0244] To take a broader perspective on this work, we note that two ofthe most important features provided by object-oriented languageslanguage features require run-time support. The first feature, “dynamicbinding”, means that the method invoked in response to a message send isdetermined at run-time. As shown by J. Gil and A. Itai, in “TheComplexity of Object Oriented Type Analysis”, Proceedings of the 11^(th)European Conference on Object-Oriented Programming (ECOOP′98), LectureNotes in Computer Science, Brussels, Belgium, July 1998, E. Jul, editor,Springer Verlag, it is next to impossible to eliminate run-time supportfor this language feature. Similarly, the next feature, “inclusionpolymorphism”, means that an object of a certain type can be addressedat run time as being of its super-type. However, it must be necessary tobe able to cast between an object and it super-type. Inclusionpolymorphism is described by L. Cardelli and P. Wegner, in “OnUnderstanding Types, Data Abstractions, and Polymorphism”, ACM Comput.Surv., 17(4): 471-522, 1985.

[0245] The language feature information that is used by the run-timesystem may be stored in objects, as compiler-generated fields, orin-tables associated with classes. However, even when information isstored in class tables, any object that needs that information must havea compiler-generated field to access the information from the classtable.

[0246] The overheads due to dynamic binding and inclusion polymorphismare minimal when there is only single inheritance: each object containsexactly one compiler generated field; method addresses are storedexactly once in each class table; no indirection is involved inaccessing data members; up-and-down-casting involve no operation; andmethod dispatch involves only a simple table lookup.

[0247] The combination of multiple repeated inheritance and these twofeatures increase the incurred overheads significantly. The number ofcompiler generated fields per object becomes non-constant, a class maystore multiple copies of a method address, casting may require a “thisadjustment” (that is, an object's pointer is adjusted to point withinthe object from one subobject to another) and dispatch becomes morecomplicated. Overheads increase even more with shared multipleinheritance, since even data member access and casting may requireredirection.

[0248] The challenge of implementing object oriented language is tominimize overheads of multiple inheritance of the shared and therepeated kind, bringing them as close as possible to those of singleinheritance. The techniques of the present invention are concrete meansto be used in meeting this challenge.

[0249] A description of related work will now be given. There are fewprevious attempts to optimize memory-space in C++ or in any otherlanguage which uses multiple inheritance. A technique tounidirectionally share a VPTR with a virtual base is described by M.Burke, H. Srinivasan, and P. Sweeney, in “A Framework for EvaluatingSpace and Time Overhead for C++ Object Models”, Research Report RC20421, IBM, T J Watson Research Center, March 1996, Declassified January1998. A necessary condition for the applicability of their technique isthat either the virtual base or the derived class have no data members.Sharing VPTR with a virtual base is another means for augmenting thetraditional object layout scheme. It is orthogonal to the techniques ofthe present invention, and would be easily incorporated into the set oftechniques described herein.

[0250] The above referenced article by D. Bacon, entitled “Fast andEffective Optimization of Statically Typed Object-Oriented Languages”,describes an algorithm for devirtualization. However, as explainedabove, that algorithm produced an erroneous result when presented withduplicated classes.

[0251] A variant to the traditional scheme specifies that the VPTR isplaced after the data members of the first class with virtual functions.The GNU CC compiler version 2.8.1. lays objects out in this way. Thatcompiler is described by R. M. Stallman, in “Using and Porting GNU CC”,The Free Software Foundation, February 1998. Another variant to thetraditional scheme specifies that VBPTRs are placed in VTBLs withnegative indices, while the addresses to virtual functions have positiveindices. This variant is described by S. B. Lippman, in Inside The C++Object Model, Addison-Wesley, second edition, 1996. These variants allowunidirectional sharing but do not allow bidirectional sharing, which isone of the main optimization techniques of the present invention.

[0252] A bidirectional record layout algorithm that allows a fixedoffset to be assigned to each field of a record in higher-orderpolymorphic programming languages with multiple inheritance is describedby W. Pugh and G. Weddell, in “Two-directional Record Layout forMultiple Inheritance”, Proceedings of the ACM SIGPLAN′90 Conference onProgramming Design and Implementation” (PLDI′90), White Plains, N.Y.,pp. 85-91, June 1990 (also published as ACM SIGPLAN Notices 25(6),1990). Their methods do not directing apply to the techniques of thepresent invention (or the traditional way that multiple inheritance isimplemented in C++) since they do not allow a subobject to start at adifferent offset than its containing object. In addition, in theirapproach, fields, not objects, are assigned direction.

[0253] A more related work, which used bidirectional in the context ofthe Theta programming language whose multiple inheritance semantics aresimilar to that of JAVA, is described by A. C. Myers, in “BidirectionalObject Layout for Separate Compilation”, Proceedings of the 10^(th)Annual Conference on Object-Oriented Programming Systems, Languages, andApplications (OOP-SLA′95), pp. 124-139, Austin, Tex., USA, October 15-191995 (also published in ACM SIGPLAN Notices 30(10), October 1995). Myerswork is restricted in scope compared to the present invention. Inparticular, only class tables are laid out bidirectionally, whileunidirectional layout is still used for objects. Furthermore, allmultiple inheritance is assumed to be nonvirtual. Myers proposed thefollowing strategies for dealing with the problem of direct access to asubobject: (i) restricting the language semantics so that, in effect,all data members are private in the C++ jargon; (ii) access to all datamembers is always done by indirection with offsets stored in the classtable; and (iii) a hybrid approach using both (i) and (ii). The firststrategy is tantamount to the demand that a class designer providesspecial methods to access data members, if these data members might beused by inherited classes. A time penalty in accessing data members isincurred in all of these strategies.

[0254] Hereinbelow, we have applied our techniques to a number ofexamples. Designing a global strategy for applying these techniques toapplications is far from being trivial. This is due to two reasons.First, the techniques interact in subtle and nontrivial ways. Whendeciding to inline a virtual base into a derived class, the effect onbidirectional marriage should be taken into account to achieve the bestresult. Second, the inlining algorithms are not fully specified.

[0255] By running a maximal independent set algorithm in inline-VBpresented above, we have implicitly assumed that all classes are“equal”. In other words, that it is always better to inline a certainbase into a set C, of classes than into a set C₂ if C₁>C₂, regardless ofthe classes in each set. This hypothesis ignores the number of timesclasses are instantiated, either on their own, or as subobjects of otherclasses. Moreover, even if all classes are instantiated an equal numberof times, inlining into certain classes could be better than intoothers. The potential saving in inessential virtual base points may makeclasses that have more indirect virtual bases better candidates forinlining.

[0256] Accordingly, weights could be assigned to classes, so that themaximal independent set would obtain the best results. Moreover,decisions made in one application of inline-VB on a certain class mayeffect decisions made in another application of this procedure onanother class. This is because the same inessential VBPTR can beeliminated by two different inlining decisions. Therefore, it may benecessary to take into account global considerations in applyinginline-VB.

[0257] It is to be appreciated that for steps that repeat, such as, forexample, in a calling program (e.g, eliminate-single-VI) and acorresponding called program (HCD), the result of the first performanceof that step (or one thereafter) may be stored in memory (e.g., in RAM1108) for future use when the result is required again. In such a case,a future occurrence of the repeating step need not be performed. Rather,the result of the previous step may be returned from the memory.

[0258] Although the illustrative embodiments have been described hereinwith reference to the accompanying drawings, it is to be understood thatthe present system and method is not limited to those preciseembodiments, and that various other changes and modifications may beaffected therein by one skilled in the art without departing from thescope or spirit of the invention. All such changes and modifications areintended to be included within the scope of the invention as defined bythe appended claims.

What is claimed is:
 1. A method for implementing virtual bases withfixed offsets in a class hierarchy graph corresponding to an objectoriented program, the graph having nodes representing object classes andedges representing immediate inheritance therebetween, the methodcomprising the steps of: for only one node y in a set of nodes Y thatdirectly and virtually inherit from a node x and that are not duplicatedin the graph, removing an edge e that represents that the node yvirtually inherits from the node x; and adding an edge e′ thatrepresents that the node x has a fixed offset with respect to the nodey.
 2. The method according to claim 1, further comprising at least oneof the steps of: eliminating transitive edges in the graph; anddevirtualizing single inheritance edges in the graph.
 3. The methodaccording to claim 2, wherein said eliminating and devirtualizing stepsare performed prior to said step of removing an edge e.
 4. The methodaccording to claim 3, wherein said eliminating step is performed priorto said devirtualizing step.
 5. A method for implementing virtual baseswith fixed offsets in a class hierarchy graph corresponding to an objectoriented program, the graph having nodes representing object classes andedges representing immediate inheritance therebetween, the methodcomprising the steps of: determining whether a set N is empty, the set Ncomprising all nodes in the graph; removing a node x from the set N,when the set N is not empty; determining whether a set Y is empty, theset Y comprising nodes that directly and virtually inherit from the nodex; returning to said step of determining whether the set N is empty,when the set Y is empty. removing a node y from the set Y, when the setY is not empty; determining whether the node y is duplicated in thegraph; returning to said step of determining whether the set Y is empty,when the node y is duplicated; and replacing an edge e with an edge e′,when the node y is not duplicated, the edge e representing that the nodey directly and virtually inherits from the node x and the edge e′representing that the node x has a fixed offset with respect to the nodey.
 6. The method according to claim 5, further comprising the step ofreturning to said step of determining whether the set N is empty, uponreplacing the edge e.
 7. The method according to claim 5, furthercomprising the step of terminating said method, when the set N is empty.8. The method according to claim 5, wherein said step of determiningwhether the node y is duplicated in the graph comprises the steps of:determining whether a set V is empty, the set V comprising nodes thatdirectly and nonvirtually inherit from the node y; removing a node ufrom the set V, when the set V is not empty; determining whether thenode u is duplicated; determining whether a set V′ is empty, when thenode u is not duplicated in the graph, the set V′ comprising nodes thatdirectly inherit from the node y and that are not the node u; returningto said step of determining whether the set V is empty, when the set V′is empty removing a node v from the set V′, when the set V′ is notempty; determining whether the node u and the node v have a commondescendant; returning to said step of determining whether the set V′ isempty, when the node u and the node v do not have a common descendant;identifying that the node y is duplicated, when one of the node u isduplicated, and the node u and the node v have a common descendant; andidentifying that the node y is not duplicated, when the set V is empty.9. The method according to claim 8, wherein said step of determiningwhether the node u and the node v have a common descendant comprises thesteps of: determining whether a set L is empty, the set L comprising allthe nodes in the graph; removing a node w from the set L, when the set Lis not empty; determining whether one of the node w is the node u andthe node w inherits from the node u, and whether one of the node w isthe node v and the node w inherits from the node v; returning to saidstep of determining whether the set L is empty, when one of the node wis not the node u and the node w does not inherit from the node u, andone of the node w is not the node v and the node w does not inherit fromthe node v; identifying the nodes u and v as having a common descendant,when one of the node w is the node u and the node w inherits from thenode u, and one of the node w is the node v and the node w inherits fromthe node v; and identifying the nodes u and v as not having a commondescendant, when the set L is empty.
 10. The method according to claim5, further comprising at least one of the steps of: eliminatingtransitive edges in the graph; and devirtualizing single inheritanceedges in the graph.
 11. The method according to claim 10, wherein saideliminating and devirtualizing steps are performed prior to said step ofdetermining whether the set N is empty.
 12. The method according toclaim 11, wherein said eliminating step is performed prior to saiddevirtualizing step.
 13. The method according to claim 10, wherein saideliminating step comprises the steps of: determining whether a set M isempty, the set M comprising the nodes in the graph; removing a node mfrom the set M, when the set M is not empty; determining whether a setM′ is empty, the set M′ comprising nodes that directly and virtuallyinherit from the node m; returning to said step of determining whetherthe set M is empty, when the set M′ is empty; removing a node m′ fromthe set M′, when the set M′ is not empty; determining whether a set M″is empty, the set M″ comprising the nodes in the set M′ other-than thenode m′; returning to said step of determining whether the set M′ isempty, when the set M″ is empty; removing a node z from the set M″, whenthe set M″ is not empty; determining whether the node m′ is a base ofthe node z and not the node z; removing an edge e1 from the graph, whenthe node m′ is a base of the node z and not the node z, the edge e1representing that the node z virtually inherits from the node m;determining whether the node z is a base of the node m′ and not the nodem′, when the node m′ is not a base of the node z and is the node z;removing an edge e2 from the graph, when the node z is a base of thenode m′ and not the node m′, the edge e2 representing that the node m′virtually inherits from the node m; and returning to said step ofdetermining whether the set M″ is empty, upon one of removing the edgee1, removing the edge e2, and when the node z is not the node m′ and abase of the node m′.
 14. The method according to claim 10, wherein saiddevirtualizing step comprises the steps of: determining whether a set Pis empty, the set P comprising all the nodes in the graph; removing anode p from the set P, when the set P is not empty; determining whethera set S is empty, the set S comprising nodes that directly and virtuallyinherit from the node p and that are not duplicated in the graph;returning to said step of determining whether the set P is empty, whenthe set S is empty; removing a node s from the set S, when the set S isnot empty; determining whether a set S′ is empty, the set S′ comprisingthe nodes in the set S except the node s; removing a node s' from theset S′, when the set S′ is not empty; determining whether the node s andthe node s' have a common descendant; returning to said step ofdetermining whether the set S′ is empty, when the node s and the node s'do not have the common descendant; replacing an edge e with an edge e′,when the set S′ is empty, the edge e representing that the node sdirectly and virtually inherits from the node p, and the edge e′representing that the node s has a fixed offset with respect to the nodep; and returning to said step of determining whether the set S is empty,upon one of determining that the node s and the node s′ have the commondescendant and replacing the edge e.
 15. A method for implementingvirtual bases with fixed offsets in a class hierarchy graphcorresponding to an object oriented program, the graph having nodesrepresenting object classes and edges representing immediate inheritancetherebetween, the method comprising the steps of: determining whether aset V′ is empty, the set V′ comprising nodes that virtually inherit froma node v in the graph; removing a node u from the set V′, when the setV′ is not empty; determining whether the node u is duplicated; addingthe node u to a set V, when the node u is not duplicated in the graph,the set V initially being an empty set of nodes that directly andvirtually inherit from the node v and that are not duplicated in thegraph; returning to said step of determining whether the set V′ isempty, upon one of adding the node u to the set V and when the node u isduplicated; determining whether the set V is empty; selecting a subset Sof the set V such that the subset S is a maximal independent set in aset G, when the set V is not empty, the set G comprising a first orderedpair of the set V and a set E, the set E comprising a second orderedpair of a node u1 and a node u2, the nodes u1 and u2 included in the setV and having a common descendant in the graph; determining whether thesubset S is empty; removing a node s from the subset S, when the subsetS is not empty; and replacing an edge e with an edge e′, the edge erepresenting that the node s virtually inherits from the node v, theedge e′ representing that the node v has a fixed offset with respect tothe node s.
 16. The method according to claim 15, further comprising thestep of returning to said step of determining whether the subset S isempty, upon replacing the edge e.
 17. The method according to claim 15,further comprising the step of terminating said method, when one of theset V and the subset S is empty.
 18. The method according to claim 15,further comprising the step of eliminating transitive edges in thegraph.
 19. The method according to claim 18, wherein said eliminatingstep is performed prior to said step of determining whether the set N isempty.
 20. The method according to claim 18, wherein said eliminatingstep comprises the steps of: determining whether a set Q is empty, theset Q comprising the nodes in the graph; removing a node x from the setQ, when the set Q is not empty; determining whether a set Q′ is empty,the set Q′ comprising nodes that directly and virtually inherit from thenode x; returning to said step of determining whether the set Q isempty,.when the set Q′ is empty; removing a node y from the set Q′, whenthe set Q′ is not empty; determining whether a set Q″ is empty, the setQ″ comprising the nodes in the set Q′ other than the node y; returningto said step of determining whether the set Q′ is empty, when the set Q″is empty; removing a node z from the set Q″, when the set Q″ is notempty; determining whether the node y is a base of the node z and notthe node z; removing an edge e1 from the graph, when the node y is abase of the node z and not the node z, the edge e1 representing that thenode z virtually inherits from the node x; determining whether the nodez is a base of the node y and not the node y, when the node y is not abase of the node z and is the node z; removing an edge e2 from thegraph, when the node z is a base of the node y and not the node y, theedge e2 representing that the node y virtually inherits from the node x;and returning to said step of determining whether the set Q″ is empty,upon one of removing the edge e1, removing the edge e2, and when thenode z is a base of the node y and not the node y.